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Method and System for Seamless Handover of Mobile Devices 

in Heterogeneous Networks 

This invention relates to communication network access technologies 
and, more particularly, to a method and system for providing a seamless 
5 handover between heterogeneous networks, i.e. a transparent and 
automatic/semi-automatic switching between different network access 
technologies without interrupting active network applications or sessions. 

Background of the Invention 

In the last few years, the number of Internet users and the 

10 information offered has increased exponentially, together with the number of 
critical business and private activities relying on the network availability and the 
reliability of the connection. Even more people are used to access Internet 
frequently to make transactions (e.g. to buy goods and services, to book flights, 
to make banking transactions or trading), to access remote information (e.g. to 

is read e-mails, to download files), to communicate (e.g. to chat, to make audio- 
video communications). That number is bound to continue to increase in the 
near future, since the growing range of IP (Internet Protocol) -capable mobile 
devices (e.g. PDAs (Personal Digital Assistant), smart-phones and laptops) and 
the growing availability of broadband wireless infrastructure (e.g. Wi-Fi 

20 [Wireless Fidelity for 802.1 1 network], GPRS (General Packet Radio Service), 
UMTS (Universal Mobile Telecommunications System), EDGE (Enhanced 
Data-Rates for GSM Evolution), 1XRTT (Radio Transmission Technology), 
CDMA2000 (Code Division Multiple Access), Bluetooth, etc.) are beginning to 
change our concept of Internet access from "static" or "nomadic" to "mobile": 

25 nowadays the possibility of connecting to the Internet is no longer limited to a 
few network access points (e.g. at home, office, school or university) since it is 
possible to have network availability wherever the user is. 

Ubiquitous access availability is important but the underlying concept 
is to provide reliable and continuous Internet access during the mobility of 
30 people nowadays, i.e. a seamless handover between different network access 
technologies. This is important since not all network technologies are suited to 
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cover similar need as range, access speed, etc. Therefore, network 
technologies as e.g. GPRS based on GSM (Global System for Mobile 
Communications), UMTS, WLAN (Wireless Local Area Network) or Bluetooth 
differ greatly in their characteristics and availability. However, co-existence of 

5 different network access technologies under the Internet Protocol (IP) brings 
problems when the user switches between access technologies and/or access 
providers: since IP addresses are assigned to a fixed location in the network, 
when we refer to mobile devices a new IP network address must be assigned 
with each change of network location (access technology and/or provider). This 

10 makes impossible a transparent, mobile access, leading to the IP applications 
to be restarted (therefore losing the current session), data packets to be lost 
and transmission rate to be slowed down. 

Think about a busy manager who is working with his laptop in his 
office, connected via Ethernet or Wi-Fi to the company network. Suppose that 

is he has a meeting in another city and he must leave the office to reach the local 
airport by taxi. Suppose he is using a Client/Server application requiring an 
always-on connection to complete a business-critical transaction. This manager 
has a problem. When he leaves the office to catch the taxi, the Wi-Fi/Ethernet 
connection will be lost and the application and the session that he is using will 

20 crash with possible loss of sensitive information. In order to complete his work, 
he will have to establish a GPRS/EDGE/UMTS/etc connection and to reload the 
Client application, repeating all the necessary authentication steps. At this point, 
he is able to continue his work, but only with the limited bandwidth offered by 
GPRS, EDGE or UMTS. When he reaches the airport, where a public hot spot 

25 is available, he could work with the larger and cheaper bandwidth of Wi-Fi; but 
in order to use the Wi-Fi technology, he has to switch from his current network 
connection to the Wi-Fi connection. This obviously involves all the above- 
mentioned problems, including the application crash and the new 
authentication. It is clear that a system should be capable of managing an 

30 automatic and transparent handover between different network access 
technologies and/or access providers without interrupting active network 
applications or sessions. This need is well known in the IT (Information 
Technologies) and Telecommunication worlds, which is also shown in the prior 
art by several patent publications e.g. by Nokia Mobile Phones LTD (EP 0 998 
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094 A2), Nortel Networks Limited (EP 1 089 495 A2), Swisscom Mobile AG 
(WO 02/103978 A2), KONINKLIJKE PHILIPS ELECTRONICS N.V. (WO 
03/065682 A1 and WO 03/065654 A1), Columbitech AB (WO 02/43348 A1), 
and documents e.g. "Supporting CORBA Applications in a Mobile Environment" 

s MOBICOM '99 by HAAHR M et al., "IP mobility support" - IETF RFC 2002 - 
1996 by C. Perkins. Another important need is that such a system should be 
completely flexible in order to be easily and quickly adapted to the variation of 
wireless network standards (e.g. in the Wi-Fi environment, the introduction of 
IEEE 802.1 1g or IEEE 802.1 1 i (IEEE: Institute of Electrical and Electronics 

10 Engineers)), in order to be easily and quickly adapted to new network access 
technologies (e.g. based on the LEO [Low Earth Orbit] satellites), in order to be 
easily adapted to different OS (Operating System) (Windows, Linux, Symbian, 
PalmOS etc..) and to the future releases of such OS, and in order to be easily 
adapted to various mobile devices with different memories, computational 

15 capability and so on. Currently there are no standards providing a roaming 
service between the various kinds of wired/wireless networks. This lack of 
standards makes wired/wireless roaming a big issue if this problem is tackled at 
the lowest levels of the OSI-7 Layers Protocol Stack (Open System 
Interconnection). The prior art mentioned above satisfies the need and 

20 manages the seamless handover proposing a mechanism that modifies one of 
the layers of the OSI protocol stack (Data Link Layer, Network Layer or Session 
Layer) or that introduces one or more sub-layers (see Figures 35 and 36). But a 
modification of the OSI protocol stack requires a lot of low-level work that is 
platform dependent, i.e. that must be done every time a new OS has to be 

25 supported, and this has a negative impact on the flexibility and portability of the 
solution. Furthermore, if one or more sub-layers are introduced, one or more 
encapsulations have also to be introduced and this increments the amount of 
data to be exchanged and the likelihood of the IP packet fragmentation. 

Virtually all networks in use today are based in some fashion on the 
30 Open Systems Interconnection (OSI) reference model of the ISO (International 
Organization for Standardization) standards. The core of this standard is the 
OSI Reference Model, a set of seven layers that define the different stages that 
data must go through to travel from one device to another over a network. 
Referring to Figure 1 , an overall scheme for the standard OSI-7 Layers Protocol 
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Stack is shown. The OSI standard is the only internationally accepted 
framework of standards for communication between different systems made by 
different vendors. The OSI layers are: Physical Layer (L1), which corresponds 
to the physical network interface, deals with the physical means of transmitting 

5 data over communication lines (referring in a network environment to various 
Network Interface Cards). On L1 each node of a network, for example, with a 
packet-switched interface has an unambiguous network address, these network 
addresses being called a Data Link Control (DLC) address or a Media Access 
Control (MAC) address. In the case of networks which conform to the IEEE 802 

10 standard (such as Ethernet, for example), the DLC addresses are usually called 
MAC addresses. To be called a DLC address, an address must fulfill at least 
the OSI reference model. In other words, a DLC address, or respectively a MAC 
address, is a hardware address that identifies the node or respectively the 
physical network interface unambiguously in the network. Some protocols, such 

is as Ethernet or Token Ring, for example, use the DLC/MAC address exclusively, 
i.e. they cannot communicate with the respective node without this address. A 
circuit-switched interface, on the other hand, has no such DLC or MAC address, 
i.e. thus also no corresponding identification DLCI (DLC Identifier). Examples of 
protocols using circuit-switched interfaces are inter alia PPP (Point to Point 

20 Protocol), SLIP (Serial Line Internet Protocol) or GPRS (Generalized Packet 
Radio Service). Basic data units of L1 are "Bits". Data link Layer (L2), which is 
concerned with procedures and protocols for operating the communication 
lines. Basic data units of L2 are "Frames". Network Layer (L3), which provides 
switching and routing technologies, creating logical paths for transmitting data 

25 from node to node. This information may include network or Internet protocol 
addresses for communication nodes. L3 does not ensure reliability and its basic 
data units are "Packets". Transport Layer (L4), which defines the rules for 
information exchange, e.g. information about various network protocols. L4 
ensures that the data is transmitted reliably between the communicating 

30 systems, it disassembles and re-assembles data into smaller units for the 
Network layer. Basic data units of L4 are "Segments". Session Layer (L5), 
which negotiates communication settings, establishes, maintains and ends 
communications between the two communicating systems. It synchronizes 
operations and coordinates rules for communicating. Presentation Layer (L6), 

35 which takes the data provided by L7 and converts it into a standard format that 
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the other layers can understand. Basic data units are of L6 are "Messages". 
Application Layer (L7), which supports application and end-user processes. 
This is the layer that actually interacts with the operating system or applications 
whenever the user chooses to transfer files, read messages or perform other 

5 network-related activities. Within the OSI Reference Model, the protocols are 
what describe the rules that control horizontal communication, that is, 
conversations between processes that run at corresponding layers. At every 
layer (except layer one) these communications ultimately take the form of some 
sort of message that is sent between corresponding software elements on two 

10 or more devices. Since these messages are the mechanism for communicating 
information between protocols, they are most generally called protocol data 
units (PDUs). Each PDU has a specific format that implements the features and 
requirements of the protocol. The communication between layers higher than 
layer one is logical; the only hardware connection is at the physical layer. Thus, 

is in order for a protocol to communicate, it must pass down its PDU to the next 
lower layer for transmission. In the OSI terminology, lower layers are said to 
provide services to the layers immediately above them. One of the services that 
each layer provides is this function: to handle and to manage the data received 
from the layer above. At any particular layer N, a PDU is a complete message 

20 that implements the protocol at that layer. However, when this "layer N PDU" is 
passed down to layer N-1 , it becomes the data that the layer N-1 protocol has to 
service. Thus, the layer N protocol data unit (PDU) is called the layer N-1 
service data unit (SDU). The job of layer N-1 is to transport this SDU, which it 
does in turn by placing the layer N SDU into its own PDU format, preceding the 

25 SDU with its own headers and appending footers as necessary. This process is 
called data encapsulation, because the entire contents of the higher-layer 
message are encapsulated as the data payload of the message at the lower 
layer. What does layer N-1 do with its PDU? It passes it down to the next lower 
layer, where it is treated as a layer N-2 SDU. Layer N-2 creates a layer N-2 

30 PDU containing the layer N-1 SDU and layer N-2's headers and footers. And so 
the process continues, all the way down to the physical layer. In the theoretical 
model, what you end up with is a message at layer 1 that consists of 
application-layer data that is encapsulated with headers and/or footers from 
each of layers 7 through 2 in turn. 
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As mentioned, in the prior art we can find the following six patent 
applications, which can be regarded as representing the prior art for the issue of 
avoiding the client application shutdown during the wireless network connection 
switches. These are WO 02/103978 A2 (Swisscom Mobile AG), EP 1 089 495 

s A2 (Nortel Networks Limited), EP 0 998 094 A2 (Nokia Mobile Phones LTD), 
WO 03/065682 A1 and WO 03/065654 A1 (KONINKLIJKE PHILIPS 
ELECTRONICS N.V.) and WO 02/43348 A1 (Columbitech AB). All these patent 
applications, except WO 02/43348 A1 , make use of the concept of Mobile IP as 
described in IP Mobility Support - IETF RFC 2002 (C. Perkins - IBM IP Mobility 

10 Support - IETF RFC 2002 - October 1 996). Internet makes use of the IP 
(Internet Protocol) to route data packets (datagrams) from the source to the 
destination. The source and the destination must have an IP address unique in 
Internet in order to be reached, something like the telephone number in the 
telephony world. When the destination address of the data packets is a mobile 

15 node this means that a new IP network address must be assigned with each 
change of network location, which makes transparent mobile accesses 
impossible. These mobility problems were solved by the Mobile IP standard of 
the IETF. Mobile IP allows the mobile node to use two IP addresses. One of 
these addresses is the normal, static IP address (home address), which 

20 indicates the location of the home network, whereas the second is a dynamic IP 
care-of address, which provides information about its current point of 
attachment to the Internet. The assignment of the two addresses allows the IP 
data packets to be rerouted to the correct, momentary address of the mobile 
node. The Mobile IP provides for registering the care-of address with a Home 

25 Agent. The Home Agent is normally a fixed network node, which administers 
the two addresses of the mobile node (home address and care-of address) and 
reroutes or routes the corresponding data packets: it sends datagrams destined 
for the mobile node through an IP tunnel to the care-of address. After arriving at 
the end of the tunnel, each datagram is then delivered to the mobile node. 

30 Unfortunately, the Mobile IP of the IETF does not solve all the 

mobility problems: if, for instance, a user would like to switch between two 
different network interfaces while an IP application is running, the IP connection 
is interrupted at the moment when he leaves the old network link. This 
connection is interrupted at least until the new location, i.e. the new care-of 
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address, is known and it has been registered at the so-called Home Agent If 
the interruption time for the change exceeds the time-out delays specified e.g. 
in the TCP (Transfer Control Protocol), the IP connection is of course 
interrupted anyway. Even when the interruption time lies within the time-out 

5 delays specified e.g. in the TCP, however, the IP applications are not able to 
maintain the connection if a physical network interface is not permanently 
available. Thereby IP applications normally have to be restarted after a network 
connection switch in order to access a new IP data tunnel. WO 02/103978 A2 
provides a method and a system to avoid the interruption of service in case of 

10 network connection switch with a mechanism operating at layer 3 (Network 
layer) of the OSI-7 Layers Protocol Stack. In Figure 2 the reference numeral 10 
refers to the mobile device, 1 1 is the application layer of the IP applications and 
12 refers to the TCP layer. The solution of WO 02/103978 A2 is based on the 
three main layers or respectively main modules 131 to 134 which are 

is designated jointly as mobile module by the reference numeral 13. The first layer 
consists of a mobile IP module 131 and/or an IPSec module 132. The second 
layer is the virtual network interface 1 33 of the solution and the third layer is an 
interface administration module 134 to handle the physical network interfaces 
14-17. Finally, reference numerals 21 to 24 accordingly stand for the various 

20 heterogeneous networks and 30 designates the usual, worldwide IP backbone 
network. The Virtual IP Network Interface (133 in Figure 2) and the Interface 
Administration Module (134 in Figure 2) make transparent to the Client 
applications (11-12 in Figure 2) the care-of IP address changing. The main 
drawback of WO 02/103978 A2 is that, operating at layer 3, the implementation 

25 requires a great deal of low-level work for each supported operating system. 
This vast amount of work reduces the flexibility of this solution in case of 
variation in wireless networks standards or in .case of introduction of new 
wireless networks. WO 02/103978 A2 is based on the concepts of Mobile IP, 
and it solves its problem of IP applications restart in case of a network 

30 connection switch. Consequently all the coordination issues between the mobile 
node and the home agent have to be considered and implemented by this 
patent. Furthermore WO 02/103978 A2 requires that the Virtual IP Network 
Interface be under a custom Mobile IP and/or IPSec module (131-132 in Figure 
2) that provides Mobile IP and security features (authenticity of the interlocutors, 

35 confidentiality of the data exchanged and hashing systems to check whether the 
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data exchanged have been modified during the transport by an unauthorized 
third party). Using a custom IPSec module all the above-mentioned security 
features have to be implemented, thus the widespread security commercial 
products operating at transport (L4) or network (L3) or lower level (L2, L1 ) can't 
5 be used. This patent does not take care of how the network connection is made 
and, operating at layer 3, an automatic or semi-automatic/assisted way to make 
the connection is difficult to be achieved. The solution of WO 02/103978 A2 is 
limited in its architectural features by Mobile IP concepts, on which it's based. 

The mentioned document EP 1 089 495 A2 of Nortel shows a 

10 method and a system to make a change of the physical interfaces without the 
active IP applications being interrupted or having to be restarted because their 
link to the original interface has been lost (see Figure 3). As Figure 3 shows, the 
solution is based on a typical OSI-7 Layer Protocol Stack where reference 
numeral 16 designates the Network Layer (L3). Reference numeral 60 stands 

is for an NAA (Network Access Arbitrator), 62 are the network adapters (NICs), 64 
are the adapter drivers and 36 is a specific computer hardware platform. Nortel 
proposes an NAA (Network Access Arbitrator) 60 to reroute, via a single fixed 
MAC (Media Access Control) address of the so-called primary NIC (Network 
Interface Card) 62, the various MAC addresses of the individual configurable 

20 physical network interfaces available. The NAA 60 connects the layer 2 (Data 
Link layer) of the available NICs 62, and it reroutes the data packets from the 
primary NIC 62 to the corresponding MAC address of a further network 
interface (secondary NIC) 62. The NAA 60 provides a virtual adapter driver, and 
it requires that at least one physical interface with a MAC address must be 

25 permanently available. The major drawback of the Nortel invention is that it is 
sensitive to the definition of the network interface hardware-related address. If 
the address does not correspond to the IEEE 802 standard (MAC addresses) 
and if the new address standard has not been explicitly defined beforehand in 
the NAA, the NAA does not function with these interfaces since it can no longer 

30 reroute the MAC addresses. Another disadvantage arises from the explicit use 
of the MAC addresses: circuit-switched interfaces (GPRS, PPP (Point-to-Point 
Protocol), SLIP (Serial Line Internet Protocol)) do not have any corresponding 
MAC or network addresses. Since the NAA is able to register only devices with 
MAC addresses in order to reroute the data packets, circuit-switched interfaces 
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are not available to the NAA even though their connection to the IP layer should 
also be possible. A further disadvantage of EP 1 089 495 A2 has its origin in 
being based on the concepts of Mobile IP. In fact, EP 1 089 495 A2 solves the 
problem of IP applications restart in case of network connection switch, but 

5 consequently, all the coordination issues between the mobile node and the 
home agent have to be considered and implemented by this solution. 
Additionally, this solution does not take care of how the network connection is 
made which can be problematic for many applications. Like the solution of WO 
02/103978 A2, the solution of EP 1 089 495 A2 is limited in its architectural 

10 features by Mobile IP concepts, on which it's based. 

The mentioned document EP 0 998 094 A2 of Nokia provides 
another method and system to avoid the interruption of service in case of 
network connection switch. The mechanism of the solution operates between 
layer 2 (Data link layer) and layer 3 (Network layer) (see Figure 4). In Figure 4 

15 PD designates a Protocol Driver, NT refers to the Windows NT standards of 
Microsoft and NISD is a Network Interface Selection Driver. The main drawback 
of this solution is that, operating between layer 2 and 3, the implementation 
requires a great deal of low-level work for each supported operating system. 
This vast amount of work reduces the flexibility of this solution in case of 

20 variation in wireless networks standards or in case of introduction of new 

wireless networks. Again, EP 0 998 094 A2 is based on the concepts of Mobile 
IP to solve the problem of IP applications restart in case of network connection 
switch. Consequently all the coordination issues between the mobile node and 
the home agent have to be considered and implemented by this solution. Like 

25 the solution of WO 02/1 03978 A2 and EP 1 089 495 A2, additionally, the 
. solution of EP 0 998 094 A2 is limited in its architectural features by Mobile IP 
concepts, on which it's based. 

The mentioned document WO 03/065682 A1 provides the seamless 
handover working at the lowest three OSI layers (Physical, Data Link and 
30 Network). The routing, including detection of available networks, address 
configuration and handover is performed by a Routing Manager object (RM). 
The Routing Manager object communicates with the bearer objects handling the 
wireless network interfaces. WO 03/065682 A1 makes use of an IP-IP tunnel to 
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provide the routing mechanism, so it makes use of the packet encapsulation. 
Like Mobile IP (RFC2002), it makes use of an IP address (called IP_CLIENT, 
the home address in the Mobile IP terminology) that remains the same during a 
handover from a first communications standard to a second communications 

s standard (the changing mobile device IP address assigned by the wireless 
connectivity bearer is called IP_BEARER, the care-of address in the Mobile IP 
terminology). Finally, it has to grant the security of the communication: the 
mobile devices have to be identified and authorized in order to communicate 
with the servers. The main drawback of this solution is that, operating at layers 

10 2 and 3, the implementation requires a great deal of low-level work for each 
supported operating system. This vast amount of work reduces the flexibility of 
this solution in case of variation in wireless networks standards or in case of 
introduction of new wireless networks. Like the other solutions mentioned, this 
solution is limited in its architectural features by Mobile IP concepts, from which 

is it has been derived. 

The mentioned document WO 03/065654 A1 is very similar to the 
WO 03/065682 A1 and share with it the above described features and 
drawbacks. It also introduces the possibility that an application, modifying its 
source code, could access, in a cross-layering way, some low level information. 
20 For this reason the MWAL (Multi-Standard Wireless Adaptation Layer) provides 
an Application Programmers 1 Interface. The communication between the 
application and the MWAL daemon is made by using a couple of local socket 
(one for the commands generated by the application and one for the events 
detected by the MWAL daemon). 

25 . The mentioned document WO 02/43348 A1 provides the seamless 

handover by using an adapted Session Layer with a security sub-layer (Session 
Mobility). This adapted Session Layer has to intercept and to manage all the 
TCP/UDP traffic produced by the client and server applications in order to grant 
the seamless handover (see Figure 35). Furthermore, in order to work properly, 

30 it has to be implemented in a platform specific way and this hinder and reduce 
the platform portability. Finally, the adapted Session Layers, interacting via a 
common session protocol, must be available on the same devices that are 
running the client or the server application and not on different devices. This 
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Session Mobility gives the possibility to handle the security at Session Layer, 
making possible to provide VPN solutions to enforce strong end-to-end security 
on an application-to-application level but its major drawback is that it lacks in 
architectural flexibility, requiring the adapted Session Layer to be installed in 
5 any devices involved in the communication. 

Finally the mentioned document "Supporting CORBA Applications in 
a Mobile Environment" MOBICOM '99 by HAAHR M et al. is only one of the 
numerous solutions providing the seamless handover by offering to the client 
and server application developers a software framework with a set of API to be 
10 used. The major drawback of this kind of solutions is the backward 

compatibility. The seamless handover can be granted only if the client and 
server applications have been developed using the provided software 
framework. All the already developed and largely used client and server 
applications can't enjoy the seamless mobility. 

15 Summary of the Invention 

It is an object of this invention to propose a new method and system 
for seamless handover of mobile devices in heterogeneous networks. In 
particular the switching from one network connection to another should be 
carried out without interruption of the IP applications and makes possible an 

20 uninterrupted continuation of the program course also with real-time 

applications, if applicable, without being dependent upon specific protocols or 
network technologies or operating systems. Therefore, it is an object of this 
invention to provide a method and a system capable of managing, without being 
dependent upon different protocols or network technologies or operating 

25 systems, an automatic/semi-automatic and transparent handover between 
different network access technologies and/or access providers without 
interrupting active network applications or sessions. 

This object is attained according to the present invention through the 
elements of the independent claims. Further preferred embodiments follow, 
30 moreover, from the dependent claims and from the description. 

In particular, this object is achieved through the invention in that a 
mobile device (10) is moved between different topological network locations 
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(30/31/32/33) and transmits and/or receives data by means of different network 
access technologies without the data transfer between a Client IP application 

(11) , running on the mobile device (10), and a Server IP application (21) being 
interrupted, in that the Client IP application (1 1) of the mobile device (10) makes 

5 a request with first data units to a client-service module (12), in that the client- 
service module (12) creates second data units based on the received first data 
units and makes a request to a server-service module (22) with the second data 
units, in that the server-service module (22) creates third data units based on 
the received second data units and makes a request to the Server IP 

10 application (21) with the third data units to handle the data exchange between 
the Client IP application (11) and the Server IP application (21). 

In another embodiment, the Client IP application (11) of the mobile 
device (10) makes the request with first data units to the client-service module 

(12) by means of a first socket. In another embodiment, the client-service 
15 module (12) makes the request to the server-service module (22) with the 

second data units by means of a second socket. In another embodiment, the 
server-service module (22) makes the request to the Server IP application (21) 
with the third data units by means of a third socket. 

It another embodiment, the socket used is connection-oriented or 
20 connectionless. 

The Server IP application (21) makes a reply with fourth data units to 
the server-service module (22). The server-service module (22) creates fifth 
data units based on the received fourth data units and makes a reply to the 
client-service module (12) with the fifth data units. The client-service module 
25 (12) creates sixth data units based on the received fifth data units and makes a 
reply to the Client IP application (1 1 ) with the fifth data units. 

In yet another embodiment, when a Server IP application (21) wants 
to use a service provided by a Client IP application (11), the following steps are 
performed: the Server IP application (21) makes a request with seventh data 
30 units to the server-service module (22), the server-service module (22) creates 
eighth data units based on the received seventh data units and makes a 
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request to the client-service module (12) with the eighth data units, the client- 
service module (12) creates ninth data units based on the received eighth data 
units and makes a request to the Client IP application (1 1) with the ninth data 
units. 

5 In another embodiment, the Server IP application (21) makes the 

request with seventh data units to the server-service module (22) by means of a 
fourth socket. In another embodiment, the server-service module (22) makes 
the request to the client-service module (12) with the eighth data units by 
means of a fifth socket In another embodiment, the client-service module (12) 

10 makes the request to the Client IP application (11) with the ninth data units by 
means of a sixth socket. 

The Client IP application (11) of the mobile device (10) makes a reply 
with tenth data units to the client-service module (12). The client-service module 
(12) creates eleventh data units based on the received tenth data units and 
15 makes a reply to the server-service module (22) with the eleventh data units. 
The server-service module (22) creates twelfth data units based on the received 
eleventh data units and makes a reply to the Server IP application (21) with the 
twelfth data units. 

v.- 

In still another embodiment, if the client-service module (12) is 
20 installed on the same mobile device (10) running the Client IP application (11), it 
provides at least a server application emulation interface comprising sockets 
and server sockets used to exchange data with the Client IP application (11) 
and bound to the loopback address used to communicate with the Client IP 
application (11), and a client application emulation interface comprising sockets 
25 and server sockets used to exchange data with the server-service module (22) 
and bound to the IP address provided by the physical interface currently 
selected by the client-service module (12). 

In another embodiment, if the client-service module (12) is installed 
on any additional mobile device on the same local area network as the Client IP 
30 application mobile device (10), it provides at least a server application emulation 
interface comprising sockets and server sockets used to exchange data with the 
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Client IP application (11) and bound to the IP address provided by a first 
physical interface used to communicate with the Client IP application (11), and 
a client application emulation interface comprising sockets and server sockets 
used to exchange data with the server-service module (22) and bound to the IP 
5 address provided by a second physical interface currently selected by the client- 
service module (12). 

In addition, the server-service module (22) provides at least a server 
application emulation interface comprising sockets and server sockets used to 
exchange data with the client-service module (12) and a client application 
10 emulation interface comprising sockets and server sockets used to exchange 
data with the Server IP application (21). 

In another embodiment, the server-service module (22) is installed 
on the same device (20) running the Server IP application (21) or on a different 
device of the same network as the device (20) running the Server IP application 
is (21 ) or on any Internet node. 

In yet another embodiment, a plurality of Server IP applications (21) 
resident on one or more devices is handled by the same server-service module 
(22). 

In another embodiment, a plurality of Client IP applications (1 1 ) 
20 resident on one or more mobile devices is handled by the same client-service 
module (12). 

In another embodiment, the client-service module (12) is connected 
simultaneously to a plurality of server-service modules (22). 

In yet another embodiment, a plurality of client-service modules (12) 
25 is connected simultaneously to a single server-service module (22). 

Moreover, the Server IP application (21 ) provides a set of server 
service server sockets listening on ports known by the Client IP application (11) 
and by the client-service module (12) and by the server-service module (22). 
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The client-service module (12) provides a set of server service emulator server 
sockets listening on the same ports as the Server IP application (21) services 
and creates, for each service request received from the Client IP application 
(1 1 ), a client request emulation socket with the server-service module (22). The 
s server-service module (22) provides a set of server service emulator server 
sockets listening on a set of ports known by the client-service module (12) and 
creates, for each service request received from the client-service module (12), a 
client request emulation socket with the Server IP application (21), on the port 
of the service that the Client IP application (1 1 ) wants to use. 

10 In another embodiment, the Client IP application (11) provides a set 

of client service server sockets listening on ports known by the Server IP 
application (21) and by the client-service module (12) and by the server-service 
module (22), the server-service module (22) provides a set of client service 
emulator server sockets listening on the same ports as the Client IP application 

15 (11) services and creates, for each service request received from the Server IP 
application (21), a server request emulation socket with the client-service 
module (12) and the client-service module (12) provides a set of client service 
emulator server sockets listening on a set of ports known by the server-service 
module (22) and creates, for each service request received from the server- 

20 service module (22), a server request emulation socket with the Client IP 
application (11), on the port of the service that the Server IP application (21) 
wants to use. 

In another embodiment, a plurality of client-service modules (12) of 
two or more mobile devices, providing client service emulator server sockets on 
25 the same ports, is connected to the same server-service module (22) and the , 
client application emulation interface sockets of the server-service module (22) 
are bound to different Virtual IP addresses created and/or allocated by it. 

In addition, the server-service module (22) provides at least one 
control server socket listening on a port known by the client-service module 
30 (12). The client-service module (12), to exchange data with the server-service 
module (22), creates at least one control socket with the server-service module 
(22). 
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Moreover, the client-service module (12) periodically checks the 
mobile device, in which it is installed, for available and configurable physical 
network interfaces and creates a lookup table with the available and 
configurable ones. With a sudden or planned change or update of a physical 

5 network interface that causes a modification of the IP address currently used by 
the client-service module (12) to access the server-service module (22), the 
data transfer between the Client IP application (11) and the Server IP 
application (21) is suspended but, in order to provide the seamless handover, 
kept up until the client-service module (12) has obtained a new IP address 

10 using the lookup table and has established a new network connection with the 
server-service module (22). The data transfer between the Client IP application 
(1 1) and the Server IP application (21 ) is resumed after that the client-service 
module (12) and the server-service module (22) have completed the 
handshaking for the switching procedure from the old IP address to the new one 

is and, in case of a sudden IP transition, after that the client-service module (12) 
and the server-service module (22) have resent the data not received by the 
other end. 



In another embodiment, the client-service module (12) automatically 
changes and updates the physical network interface currently used to access 
20 the server-service module (22) on the basis of information retrieved from the 
lookup table. 



In another embodiment, the criteria for the automatic change and/or 
update of the physical network interface currently used by the client-service 
module (12) to access the server-service module (22) are defined by the user. 

25 In another embodiment, a change or an update of the physical 

network interface currently used by the client-service module (12) to access the 
server-service module (22) is initiated by the user. 



30 



In yet another embodiment, the client-service module (12) and/or the 
server-service module (22) are OSI Layer 7 applications and are created as 
platform independent applications. 
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In still another embodiment, the client-service module (12) and/or the 
server-service module (22) are at least in part composed by Java modules. 

Finally, the data transfer is realized by means of IEEE 802.1 1 and/or 
IEEE 802.16 and/or GPRS and/or EDGE and/or UMTS and/or CDMA2000 
5 and/or Bluetooth and/or ZigBee and/or PSTN and/or ADSL and/or Ethernet 
and/or Token Ring and/or FDDI. 



In particular, the movement between different topological network 
locations while transmitting and/or receiving data by means of different network 
access technologies can, for instance, comprise a change of the physical 

10 network interface and/or a change among different networks technologies, such 
as e.g. Ethernet, Bluetooth, mobile radio networks (GSM, EDGE, GPRS, 
CDMA200, UMTS, etc.) or WLAN (Wireless Local Area Network), or also a 
topological location change within the same network technology, for example a 
device linked to an Ethernet network that migrates to another Ethernet network 

is or a device linked to a Wi-Fi HotSpot that migrates to another Wi-Fi HotSpot. 

It should be stated here that, besides the method according to the 
invention, the present invention also relates to a system and a computer 
program product for carrying out the method. 

Distinctive characteristics of the Invention 

20 This invention provides the seamless handover using a completely 

different approach compared with the solutions of the prior art mentioned 
above. It does not modify any OSI protocol stack layer and it does not introduce 
any sub-layer (see Figures 33,34,35,36). The seamless handover is obtained by 
a pair of applications (OSI Layer 7), which deceive the Client and the Server 

25 applications letting them believe that they are running on the same device, or on 
different devices belonging to the same network. The Client and the Server 
applications do not realize that they are communicating via the Internet. This 
invention solves the problem of the IP address switch by introducing two 
applications collectively acting as a middleware: the CNAPT (Client Network 

30 Address and Port Translator) and the SNAPT (Server Network Address and 
Port Translator). These two components interface the communication between 
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the Client and the Server hiding the mobility to them. The CNAPT is an 
application that can be installed on the same device as the Client application or 
in a different device in the same mobile network (e.g. a team of consultants, 
maintenance workers, auditors that require mobility while working together; in 

5 this case the CNAPT can be installed in only one of the mobile devices of the 
mobile network and all the team can share the seamless handover provided by 
it). The SNAPT is an application that can be installed in the same device as the 
Server application or in a different device of the same network or in any Internet 
server (on a corporate front-end server, on the home PC or in any Internet node 

10 or router). This feature is particularly important because provides a way to 
eliminate the scalability problem that affects each of the solutions mentioned in 
the prior art. With this invention it is possible, but not necessary, to have big 
servers with large bandwidth managed by telecom companies or ISP or 
individual companies to handle the mobility of multiple users. This invention 

15 provides, in fact also, the possibility to each user to manage its mobility by itself 
by installing the SNAPT on any Internet node (e.g. on the home PC if directly 
connected to the Internet). This is a completely new approach: the mobility 
handling can be distributed and not only centralized as in the prior art. 

This invention provides a seamless handover solution using a pair of 
20 applications which re-route data without any modification of the OSI protocol 
stack and without any modification of the Client and Server applications source 
code. The Client application must only be set to consider the CNAPT as its 
Server application (e.g. its TCP/UDP segments have to be addressed to the 
CNAPT IP address and not to the Server application IP address); this can be 
25 done statically by modifying its configuration file (if present) or dynamically at 
run time through its GUI (if provided). The Client application data (payload) 
arrives to the CNAPT, e.g. inside a TCP/UDP segment, and then the CNAPT 
forwards only the payload e.g. inside a new TCP/UDP segment to the SNAPT 
making an address and port translation, without any encapsulation (in the sense 
30 that no one byte is added to the original payload). The SNAPT forwards the 
payload received by the CNAPT, e.g. in a new TCP/UDP segment, to the 
Server application making an address and port translation (see Figure 33). The 
Server application receives the TCP/UDP segment sent by the SNAPT 
considering it as coming from the Client application. The data sent by the 
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Server application follow a mirror path of the Client application data. The 
address and port translations only require the modification of the transport 
header (TH) and the network header (NH). This invention requires two 
additional sockets for each Client/Server socket The Client/Server socket is 
s replaced at application layer by a Client application/CNAPT socket, a 

CNAPT/SNAPT socket and a SNAPT/Server application socket (see Figure 33). 

If the mobile device running the CNAPT application changes its IP 
address and if the time requested by the IP transition phase is smaller than the 
Client/Server application timeout, the Client and the Server applications 
10 interaction only suffers a temporary reduction of the quantity of data transmitted 
per unit of time (throughput) and a delay in the replies proportional to the length 
of the IP transition phase. No one byte is lost or corrupted during the IP 
transition phase. 

All operations of the CNAPT application and the SNAPT application 

15 are performed according to the invention at application level (OSI Layer 7). 
Operating at the highest level of abstraction, i.e. at the highest layer, this 
invention has the advantage that all activities can be easily and quickly adapted 
to the evolution of wireless networks standards, to new network access 
technologies, to the different Operating Systems (Windows 98/2000/2003/XP, 

20 Windows CE/PocketPC, Symbian, PalmOS, Linux and so on) and to future 
releases of such Operating Systems. A high degree of platform independency 
can be achieved by implementing the CNAPT and the SNAPT applications in 
Java. Moreover, operating at layer 7, this invention has many further 
advantages compared to the methods and systems of prior art: (1) It does not 

25 have to take care of Mobile IP concepts and implementation; i.e. it works in a 
transparent way over Mobile IP (v4 or v6) exactly as it works over IPv4 or IPv6. 
(2) It can use all the widespread commercial products operating at session (L5), 
transport (L4) or network (L3) or lower level (L1 , L2) to manage the security and 
to provide all the security features. Particularly, it does not require the 

30 implementation of any custom security feature: it can work in a transparent way 
over IPSec (IP Security by IETF (Internet Engineering Task Force)), L2TP 
(Layer Two Tunnelling Protocol) or other VPN (Virtual Private Network) 
protocols. (3) It does not care what kind of network connection is used, and the 
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invention thereby works indifferently in circuit-switched and packet-switched 
networks. (4) It provides an automatic and/or a semi-automatic/assisted way to 
make network connections. The comparison of this invention with the prior art 
highlights its innovative idea and its advantages. Operating at layer 7, this 
5 invention provides an extreme flexible and simple way to solve the problem of 
the interruption of service in case of network connection switch. 

Short description of the drawings 

Various embodiments of the present invention will be described in 
the following with reference to examples. The examples of the embodiments are 
10 illustrated by some of the following attached figures: 

Figure 1 shows a block diagram illustrating schematically the OSI-7 
Layers Protocol Stack as defined in the prior art. 

Figure 2 shows a block diagram illustrating schematically the 
architecture of WO 02/103978 A2 of the prior art. 

is Figure 3 shows a block diagram illustrating schematically the 

architecture of EP 1 089495 A2 of the prior art. 

Figure 4 shows a block diagram illustrating schematically the 
architecture of EP 0998094 A2 of the prior art. 

Figure 5 shows a block diagram illustrating schematically a 
20 Client/Server application using Internet to exchange data. 

Figure 6 shows a block diagram illustrating schematically the Client 
application using a local network connection and the Internet to reach its Server 
application. 

Figure 7 shows a block diagram illustrating schematically the Client 
25 application sending a request of service A to its appropriate Server application. 



WO 2005/076651 



PCT/EP2005/050599 



21 



Figure 8 shows a block diagram illustrating schematically the CNAPT 
module according to the invention. 

Figure 9 shows a block diagram illustrating schematically the CNAPT 
and the Client application installed on different devices directly linked to form a 
5 PAN (Personal Area Network). 

Figure 10 shows a block diagram illustrating schematically the 
SNAPT module according to the invention. 

Figure 1 1 shows a block diagram illustrating schematically an 
embodiment according to the invention, the "Basic configuration". 

10 Figure 12 shows a block diagram illustrating schematically an 

embodiment variant according to the invention, the "Multi-Site configuration". 

Figure 13 shows a block diagram illustrating schematically an 
embodiment variant according to the invention, the "Client PAN configuration". 

Figure 14 shows a block diagram illustrating schematically an 
is embodiment variant according to the invention, the "Multi-Server LAN 
configuration". 

Figure 15 shows a block diagram illustrating schematically an 
embodiment variant according to the invention, the "Multi-Server Internet 
configuration". 

20 Figure 16 shows a block diagram illustrating schematically an 

embodiment variant according to the invention, the "Client PAN Multi-Server 
Internet configuration". 

Figure 17 shows a block diagram illustrating schematically an 
embodiment according to the invention based on the "Basic configuration" 
25 where the Client application uses a local network connection and the Internet to 
reach its server application. 
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Figure 18 shows a block diagram illustrating schematically the 
CNAPT/Client application interaction of an embodiment according to the 
invention based on the "Basic configuration". 

Figure 19 shows a flowchart illustrating schematically the method 
5 used by "Search Activity" to search for alternative network providers. 

Figure 20 shows a flowchart illustrating schematically the method 
used by CNAPT module to retrieve an Internet connection at its start. 

Figure 21 shows a block diagram illustrating schematically the 
SNAPT/Server application interaction of an embodiment according to the 
10 invention based on the "Basic configuration". 

Figure 22 shows a block diagram illustrating schematically a 
Client/Server interaction by a system according to the invention. 

Figure 23 shows a block diagram illustrating schematically the 
CNAPT module stopping forwarding service requests and sending a 
is SWITCI-LSTEP1 packet. 

Figure 24 shows a block diagram illustrating schematically the 
SNAPT module stopping forwarding data packets and sending an 
acknowledgement packet and the LAST_M ES SAG E_B E FO RE_RE D I RECT I ON 
packets. 

20 Figure 25 shows a block diagram illustrating schematically the 

CNAPT module sending the LAST_MESSAGE_BEFORE__REDIRECTION 
packets. 

Figure 26 shows a block diagram illustrating schematically the 
SNAPT module sending the OK_TO_REDIRECTION packet. 
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Figure 27 shows a block diagram illustrating schematically the 
CNAPT module sending the CLIENT_SERVICE_READY_FOR_REDIRECTION 
packet. 

Figure 28 shows a block diagram illustrating schematically the 
5 SNAPT module sending the 

SERVER_SERVICE_READY_FOR_REDIRECTION packet. 

Figure 29 shows a block diagram illustrating schematically the 
CNAPT module sending the SWITCH_STEP2 packet, destroying the Client 
request emulation sockets and replacing the control socket. 

10 Figure 30 shows a block diagram illustrating schematically the 

CNAPT module recreating the Client request emulation sockets and binding 
them to the new IP address. 

Figure 31 shows a block diagram illustrating schematically the 
SNAPT module sending the ALLJREDIRECTED packet. 

15 Figure 32 shows a block diagram illustrating schematically the IP 

transition phase completed without any interruption of service. 

Figure 33 shows a block diagram illustrating schematically the 
payload path from a Client application to a Server application while using the 
CNAPT and the SNAPT. 

20 Figure 34 shows a block diagram illustrating schematically the 

payload path and the network layer headers from a Client application to a 
Server application while using the CNAPT and the SNAPT. 

Figure 35 shows a block diagram illustrating schematically the 
payload path and the network layer headers from a Client application to a 
25 Server application while using the solution WO 02/43348 A1 by Columbitech 
AB. 
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Figure 36 shows a block diagram illustrating schematically the 
payload path and the network layer headers from a Client application to a 
Server application while using one of WO 02/103978 by Swisscom Mobile AG, 
EP 1089495 A2 by Nortel Networks Limited, EP 0998094 A2 by Nokia Mobile 
s Phones LTD, WO 03/065682 A1 or WO 03/065654 A1 by KONINKLIJKE 
PHILIPS ELECTRONICS N.V.. 

Description of the Invention 

To be understood as computer or device, in this document, are, inter 
alia, all possible so-called Customer Premise Equipment (CPE): PC, routers, 
10 laptop, PDA, smart-phones etc. 

To be understood as socket is, in this document, the Internet socket, 
i.e. one end of a bi-directional communication link between two programs 
defined as the combination of an IP address and a port number. 

Figure 5 to 1 1 illustrate an architecture that can be used to achieve 
the invention. The invention can be used by any Client application that is 
connected through an IP network (e.g. Internet or any wired/wireless Intranet) to 
its Server application (Figure 5). The method and system according to the 
invention comprise one or more Client applications 1 1 , running on a mobile 
device 10, that are connected via a local network provider 30/31/32/33 and 
through an IP network 34, e.g. the worldwide backbone network called Internet 
or any wired/wireless Intranet, to a Server application 21 (Figure 6). The 
networks implemented by providers 30/31/32/33 can comprise Ethernet or 
another wired LAN (Local Area Network), Bluetooth, GSM (Global System for 
Mobile Communication), GPRS (Generalized Packet Radio Service), EDGE 
(Enhanced Data-Rates for GSM Evolution), 1XRTT (Radio Transmission 
Technology), CDMA2000 (Code Division Multiple Access), UMTS (Universal 
Mobile Telecommunications System) and/or WLAN (Wireless Local Area 
Network), etc. To be understood as mobile device 10 are, inter alia, all possible 
devices (laptops, PDAs, smart-phones etc) and in general all so-called 
Customer Premise Equipment (CPE) equipped with one or more different 
physical network interfaces 40 to 43, which can also support the different 
network standards of the various network providers 30 to 33. The physical 
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network interfaces 40 to 43 of the mobile device 10 can comprise e.g. interfaces 
for the mentioned networks as e.g. Ethernet or another wired LAN, Bluetooth, 
GSM, GPRS, EDGE, CDMA2000, UMTS and/or WLAN, etc. The interfaces can 
be not only packet-switched interfaces, as used directly by network protocols 

5 such as e.g. Ethernet or Token Ring, but also circuit-switched interfaces which 
can be used by means of protocols such as e.g. PPP (Point-to-Point Protocol), 
SLIP (Serial Line Internet Protocol) or GPRS (Generalized Packet Radio 
Service), i.e. whose interfaces do not have, for example, any network 
addresses such as a MAC or a DLC address. The invention provides any Client 

10 application with the best local network connection to the IP network 34 in term 
of bandwidth, reliability and cost effectiveness among all the wired/wireless 
network access technologies and/or access providers available at a certain time 
and location 30/31/32/33, managing the switch (when needed or convenient) in 
a transparent automatic and/or semi-automatic way without interrupting active 

15 network applications or sessions. In particular, the switch between the networks 
can comprise a change of a physical network interface among different 
networks technologies, such as e.g. Ethernet, Bluetooth, mobile radio networks 
(GSM, GPRS, EDGE, CDMA2000, UMTS, etc.) or WLAN, or also a topological 
location change within the same network technology, for example a device 

20 linked to an Ethernet network that migrate to another Ethernet network or a 
device linked to a Wi-Fi HotSpot that migrate to another Wi-Fi HotSpot. In 
particular the invention is suited for client network applications running on a 
mobile device 10 which is able to hold simultaneously at least two different kind 
of network connection (GSM, GPRS, EDGE, CDMA2000, UMTS, Satellite 

25 Links, Wi-Fi, LAN, PSTN [Public Switched Telephone Network], xDSL as ADSL 
[asymmetric digital subscriber line] or SDSL [symmetric digital subscriber line] 
etc): for instance mobile devices with a GPRS modem and an independent Wi- 
Fi adapter or mobile devices with a Wi-Fi adapter and an independent UMTS 
modem or so on. However, it is important to note that the invention also works 

30 with mobile devices able to hold only one network connection at a time (e.g. a 
laptop that possesses only one slot for insertion of a PCMCIA network card 
(PCMCIA: Personal Computer Memory Card International Association)). 
According to the invention the client application and its server exchange data 
via an IP network, such as e.g. the Internet, using exactly one network 

35 connection at a time. 
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Suppose that the mobile device using the client application is able to 
provide N different network connections through N network adapters (with N>1 ) 
(40-43). The server application may provide one or more services and for each 
of them a server socket 29 listens for client application requests (Figure 6). 

s Suppose further that the mobile device is e.g. connected to Internet via the 
network provider X [31] and has the IP address M ClientlP_X w . Besides, suppose 
that a second network provider, provider Y [32], is available at the same time. 
The client application now uses a socket to send its server a service request. 
The server replies with packets having "ClientlP_X n as destination IP address 

10 (Figure 7). If Provider X becomes unavailable (slowly, e.g. the Provider X is a 
Wireless provider and the mobile device is slowly leaving its coverage area, or 
suddenly, e.g. the LAN/Ethernet cable is suddenly unplugged), while the other 
Provider Y remains still available, a new network connection through the 
Provider Y must be established, in order to maintain active the client application 

is and the current session. When established, the old network connection, if 

already up, should be closed because it will no longer be available. The problem 
is that with the new network connection, the mobile device will be assigned a 
new IP address (therefore changing its IP address from "ClientlP_X w to 
"ClientlP^Y"): due to such a change, the service response can no longer reach 

20 the client application, resulting in the application/session crash and interruption 
of the service. 

The invention avoids any interruption of service without any 
modification of the providers' infrastructure. One of the purposes of invention is 
to make the IP address change of the mobile device totally transparent to the 

25 client and server applications. The invention acts as a middleware, making the 
client application to believe that it is running either on the same device as the 
server application or in a device directly connected to the server (depending on 
the configuration adopted). This is achieved through the client-service module 
12, further called CNAPT (Client Network Address and Port Translator) (Figure 

30 8), and a server-service module 22, further called SNAPT (Server Network 
Address and Port Translator) (Figure 10). By means of the CNAPT module and 
SNAPT module, if the provider X becomes unavailable (slowly or suddenly) 
while the network provider Y remains still available, and if there is enough time 
for the IP transition phase (that is to say the client and the server applications 
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do not go into timeout), the switch between K ClientlP_X" and "ClientlP_Y" is 
totally transparent to the client and server applications that continue their 
execution without any session crash and/or interruption of service. Note that the 
IP transition phase can be generated also by a temporary interruption of the 

5 Internet connection provided by the network provider X, that however remains 
still available; in fact that temporary interruption may cause a modification on 
the assigned IP address, e.g. from "Client^X" to K ClientlP_X1". During the IP 
transition phase: (1) The CNAPT stops forwarding all the outgoing IP packets 
generated by the Client application. They are buffered by the CNAPT and they 

10 will be forwarded at the end of the IP transition phase. (2) The SNAPT stops 
forwarding all the outgoing IP packets generated by the Server application and 
directed to the switching CNAPT. They are buffered by the SNAPT and they will 
be forwarded to the switching CNAPT at the end of the IP transition phase. 

Comprising the CNAPT module and the SNAPT module the invention 
15 is able to act as a layer 7 relay system with a high level of flexibility. The 
CNAPT module processes the client requests and relays them to the SNAPT 
module. The SNAPT module processes the client requests and, at its turn, 
relays them to the server application. The server response path is the mirror 
image of the client request. The CNAPT module and the SNAPT module 
20 comprise the necessary infrastructure, including hardware and software 
components and/or units, to achieve a described method and/or system 
according to the invention. 

According to the invention, the Server IP address is modifiable in the 
client application (i.e. the Server IP address is not hard coded). The SNAPT 

25 module comprises in an appropriate memory unit at least the server IP address 
(or, in turn, the servers' IP addresses in case of multiple server applications, 
running on different devices, managed by the same SNAPT module), the server 
services 1 ports and the server services' type (connection-oriented, like services 
based on TCP (Transmission Control Protocol), or connectionless, like services 

30 based on UDP (User Datagram Protocol)) of its managed server application. 
The SNAPT module comprises means to emulate server services 29 providing 
a set of emulation services 26 operating on emulation ports different from the 
real services port in order to avoid bind errors (Figure 10). Each CNAPT module 
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comprises a unique ID (IDentification Number) that differentiates it from the 
other CNAPT modules. The CNAPT module further comprises in a memory unit 
at least the SNAPT IP address (or, in turn, the SNAPTs' IP addresses in case of 
a CNAPT module simultaneously connected to more than one SNAPT module), 

5 the server services' ports and type (connection-oriented or connectionless) of 
the server application managed by the SNAPT and the SNAPT module 
services' emulator ports. The CNAPT module also comprises in a memory unit 
the client IP address (or, in turn, the clients' IP addresses in case of multiple 
client applications, running on different devices, managed by the same CNAPT 

10 module), the eventual client services' ports and the client services' type 
(connection-oriented or connectionless) of its managed client application. 
Finally the CNAPT module comprises means to emulate the eventual client 
services 111 providing a set of emulation services 17 operating on emulation 
ports different from the real services ports in order to avoid bind errors (Figure 

is 8). The SNAPT module comprises, for each CNAPT module that provides client 
services, the client services' ports, the CNAPT services' emulator ports and the 
client services' type (connection-oriented or connectionless). These data are 
grouped by CNAPT module ID. If the client services are used, the SNAPT 
module must comprise also a set of virtual IP addresses 23 (Figure 10) 

20 belonging to the same network to which it belongs (i.e. if the SNAPT module 
has the IP 192.168.102.150 and belongs to the network 192.168.102/24, it must 
have a set of virtual IP addresses belonging to 192.168.102/24 like 
192.168.102.151, 192.168.102.152 and so on). Those addresses are used to 
accept simultaneous connections of different CNAPT modules managing client 

25 applications providing their client services on the same port, in order to avoid 
bind errors on that port. This is the case e.g. of n identical CNAPT modules 
managing a client application providing a client service on the port X, connected 
to a single SNAPT module. A different virtual IP address is used for each of 
those identical CNAPT modules. Obviously the number of virtual IP addresses 

30 must be equal to the number of those identical CNAPT modules that can 

access the SNAPT module simultaneously. During normal activity the SNAPT 
module knows the CNAPT module ID and the current IP of all the connected 
CNAPT modules. 
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As explained before, the invention comprises the possibility that the 
client application could also provide a set of services (connectionless or 
connection-oriented), the client services, that can be used by the server 
application for "PUSH" or "Publish/Subscribe" paradigms. For instance, the 

5 client application contacts the server application to register for some information 
updates, so when new information becomes available the server application 
may "push" them to the subscribed client applications on their services' ports. 
From now on, to simplify the explanation and the drawings, only the services 
provided by the server application are considered: it is easy to understand that 

10 client services are managed by the invention in a mirror-like manner to the 
server services. 

It is important to note that the invention does not require any 
modification of the client applications source code if: (a) The server IP address 
is not hard coded (that is to say the server IP address is not set directly in the 

15 source code). It must be possible to set the server IP address in a configuration 
file or at run time, with user 1 interaction (Figure 6), in some client application 
input mask, (b) The source IP address of the eventual client services provided 
is not hard coded. It must be possible to set the source IP address of these 
client services to "loopback" address (the special address "127.0.0.1" for IPv4 

20 and the for IPv6) in a configuration file or at run time, with user 1 

interaction, in some Client application input mask. This is necessary because if 
the source IP address is set automatically to the mobile device IP, when this IP 
address changes for a switch phase the client services would be interrupted. 
This constraint is not necessary if the client applications 1 1 are running on 

25 devices 10 different from the CNAPT module device 13 (Figure 9). In fact, in 
this case the source IP address is the client application device PAN IP address 
18 (PAN: Personal Area Network) and it does not change during a switch phase 
(only the CNAPT module Internet IP address 19 changes during a switch 
phase). The invention does not require any modification of the Server 

30 application source code unless the client IP address, retrieved from the 

incoming packets, is used for critical internal activities (for instance in case of 
authentication based on the client IP address). 
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The CNAPT module according to the invention can be realized by 
means of appropriate software and/or hardware components. The CNAPT 
module comprises means to emulate server applications on the client side 14 
and means to emulate client applications on the network side 15, e.g. Internet 

5 side (Figure 8). The CNAPT module creates for each server service, a server 
socket 16 on the client side. This server socket listens on the real server service 
port (server service emulator server socket). For each server service request, 
the CNAPT module provides a client request emulation socket 121 on the 
Internet side. This socket relays packets to the right service emulator server 

10 socket provided by SNAPT. For each client service 111, the CNAPT module 
provides a server socket 17 on the network side, e.g. on the Internet side. This 
server socket listens on (i.e. waits for a signal on) the client service emulator 
port (client service emulator server socket). This port is different from the client 
service real port in order to avoid a bind error. For each client service request, 

15 the CNAPT module provides a server request emulation socket 123 on the 
client side. This socket relays packets to the real Client server socket. 

The CNAPT module not only acts as a layer 7 relay system. It also 
launches a "decision task" module in order to provide the client application with 
the best network connection, e.g. Internet connection, in term of bandwidth, 

20 reliability and cost effectiveness. The "decision task" module can be realized as 
a software and/or hardware module and has two main activities: (1) It 
continuously verifies the current network connection reliability and performance 
(Check Activity). (2) It continuously searches for new network providers (Search 
Activity). At any time, the user 1 can ask to the "decision task" module to switch 

25 to another available network provider. This is useful when the current network 
connection is a wired connection and the user 1 wants to switch to a wireless 
connection unplugging for instance the Ethernet cable. Note that the "decision 
task" can launch the Search and the Check activities only if it is running on a 
mobile device that is able to hold simultaneously at least two different kind of 

30 network connection (GSM, GPRS, EDGE, UMTS, Satellite Links, Wi-Fi, LAN, 

PSTN, ADSI etc). If that mobile device is able to hold only one network 

connection at a time (e.g. a laptop that possesses only one slot for insertion of a 
PCMCIA network card), the Search activity can't be launched and the Check 
activity only verifies the reliability of the current Internet connection signalling to 
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the user 1 its eventual unavailability. In this case, the switch from one network 
provider to another (or also, in case of temporary interruption, to the same 
network provider if it is became available in the meanwhile, e.g. there was only 
a temporary problem) can be decided only by the user 1 with a specific request 
5 to the "decision task". 

The Check Activity as a part of the "decision task" module verifies the 
reliability and the performance of the current network connection, e.g. Internet 
connection, every Y ms. If the reliability/performance indexes go down some 
specified "warning thresholds" (that can be set by the user 1 ) or if the current 

10 Internet connection has been interrupted, the "Check Activity" searches for new 
network providers in a similar way as the Search Activity (or trying to retrieve a 
new Internet connection from the same network provider if it is became 
available in the meanwhile, e.g. there was only a temporary problem). It can 
work in two ways: manual and automatic mode. In both the modes if it does not 

is find any other network providers, it signals to the user 1 that the current network 
connection will be no longer available. In the manual mode, if it finds at least 
one alternative provider, it suggests the user 1 to switch to the better 
alternative. If and only if the user 1 does not authorize the switch and the 
current network connection indexes go down some specified "critical threshold" 

20 (that can be set by the user 1 ), the Check Activity, in order to avoid any 
interruption of service, switches to an alternative network provider available 
(preferring the provider allowing a totally automatic connection procedure) and it 
signals to the user 1 that the current network connection will be no longer 
available. In the automatic mode, if the Check Activity finds at least one 

25 alternative provider, it automatically decides on the network provider switch 
(preferring the alternative provider which allows a totally automatic connection 
procedure). It may perhaps require some user 1 interaction to establish a semi- 
automatic/assisted network connection. During the switch, the Check Activity 
avoids any interruption of service by the method described in this invention. 

30 After the switch has been made the old network connection, e.g. Internet 
connection, will be closed if it is still open. 

The Search Activity as another part of the "decision task" module 
searches, without disturbing the current connection, every X ms for other 
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available networks providers (Figure 19). It can work in two ways: manual and 
automatic mode. In the manual mode the user 1 has to choose the available 
network provider that he prefers. When the Search Activity finds at least one 
network provider that could provide a network connection, e.g. Internet 

5 connection, better than the current one, it asks the user 1 if he wants to switch. 
In the automatic mode, the Search Activity automatically decides on the network 
provider switch (the decision is made using a set of parameters that can be 
modified by the user 1 ). It may eventually require some user 1 interaction to 
establish a semi-automatic/assisted network connection. During the switch, the 

10 Search Activity avoids any interruption of service by the method described this 
invention. After the switch has been made, the old network connection, e.g. 
Internet connection, will be closed. 

The SNAPT module according to the invention can be realized by 
means of appropriate software and/or hardware components. The SNAPT 

15 module comprises means to emulate the client application on the server side 24 
and means to emulate the server application on the network side 25, e.g. 
Internet side (Figure 10). The SNAPT module creates for each server service 
29, a server socket 26 on the Internet side. This server socket listens on the 
server service emulator port (server service emulator server socket). This port is 

20 different from the server service real port in order to avoid a bind error. For each 
server service request, the SNAPT module provides a client request emulation 
socket 60 on the server side 24. This socket relays packets to the real service 
server socket. For each client service the SNAPT module creates a server 
socket 28 on the server side 24. This server socket listens on the real client 

25 service port (client service emulator server socket). The client service emulator 
server sockets are grouped by CNAPT module ID. Those groups using the 
same ports are bound to different Virtual IP addresses 23 in order to avoid bind 
errors. For each client service request, the SNAPT module provides a server 
request emulation socket 61 on the Internet side 25. This socket relays packets 

30 to the right client service emulator server socket provided by the correspondent 
CNAPT ID. Further the SNAPT module comprises a control server socket 27 on 
the network side 25. The CNAPT module communicates with the SNAPT 
module over the network 30/31/32/33/34 through this "control server socket". 
This connection is used to exchange handshaking packets during an IP 
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address-changing phase and it can be used to optimize the interaction between 
the client and the server application. 

In the following will be described an embodiment according to the 
invention and the main embodiment variants. In each embodiment, shown here, 

5 a unique client application and a unique server application are shown in the 
appended figures. Nothing changes if there are n client applications 1 1 on the 
mobile device 10 that, through the local CNAPT module, are using the services 
provided by the m server applications 21 managed by the connected SNAPT 
module on the same device 20. It is possible that each SNAPT module can 

10 accept the simultaneous connection from more than one CNAPT module. 

In a first embodiment, the "Basic configuration", the CNAPT module 
is installed on the client application mobile device 10 and the SNAPT module is 
installed on the same device 20 as the server application 21 (Figure 11). The 
server IP address is set to "loopback" (50) in the client application. The CNAPT 

is module sets the SNAPT IP address for each server service to "ServerlP" (51). 
In this configuration the CNAPT module emulates the server services on the 
client side providing a server socket "loopback:ServiceEmulator" 16 for each of 
them ("loopback:ServiceA", "loopback:ServiceB" and so on). This socket can 
handle multiple concurrent client requests. The client application accesses the 

20 services by sending and receiving data to/from these sockets. On the server 
side the SNAPT module emulates the client application requests providing a 
socket "loopbackrCasualPort" 60 for each of them. The Server application 
handles Client requests by sending and receiving data to/from these sockets. 

In an embodiment variant, the "Multi-Site configuration", the CNAPT 
25 module is installed on the client application mobile device 10 and it is connected 
simultaneously to more than one SNAPT module. Each SNAPT module is 
installed on the same device as its server application (Figure 12). The Servers 
IP addresses are set to "loopback" (50) in the client application. The CNAPT 
module sets the SNAPT IP address to "ServeM IP" for the services A,B..Z and to 
30 "Server2IP" for the services 1.2..N (51). In Figure 12 a unique client application 
and a unique server application are shown. Nothing changes if there are n client 
applications on the mobile device that, through the local CNAPT module, are 
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simultaneously using the services provided by the m server applications 
managed by all the connected SNAPT modules. This embodiment variant has 
the advantage that the system according to the invention can grant the 
seamless handover for the network connection among one or more client 
5 applications and two or more server applications running on different Internet 
nodes. With this embodiment a user 1 , without interruption of service, can move 
from one local network provider to another one keeping active multiple sessions 
with multiple different service providers. 

In an embodiment variant, the "Client PAN configuration" (PAN: 

10 Personal Area Network), the CNAPT module is installed on an additional mobile 
device 13, that could act as a "connectivity box" able to manage the highest 
possible number of network access technologies and linked to the original 
mobile device through a broadband IP connection 131 (Figure 13). The client 
application mobile device 10 and the "connectivity box" have a fixed private IP 

is address each, "ClientIP" and "CBoxlP": they are part of a very small local 
network (e.g. they are connected using an Ethernet cross cable or a Wi-Fi ad- 
hoc connection or a Bluetooth connection). The server IP address is set to the 
"connectivity box" IP address ("CBoxlP") (50) in the client application. The 
CNAPT module sets the SNAPT module IP address for each server service to 

20 "ServerIP" (51). The CNAPT module comprises means to emulate the server 
services providing, on the client side, a server socket "CBoxlP: 
ServiceEmulator" 16 for each of them ("CBoxlP:ServiceA", " CBoxlP:ServiceB" 
and so on). This socket can handle multiple concurrent client requests. The 
client application accesses the services by sending and receiving data to/from 

25 these sockets. On the server side the SNAPT module comprises means to 
emulate the client application requests providing a socket 
"loopback:CasualPorf 60 for each of them. The server application handles 
client requests by sending and receiving data to/from these sockets. This 
embodiment variant has the advantage that the user 1 has to interact with a 

30 mobile device 10 simpler and maybe smaller than in the previous embodiments. 
In the previous embodiments this mobile device should have more than one 
network adapter and it must run the CNAPT module and the client application. 
In this embodiment variant instead it must have only one network adapter and it 
must run only the client application, while the system according to the invention, 



WO 2005/076651 



PCT/EP2005/050599 



35 

granting the seamless handover, is provided by the "connectivity box". Another 
advantage of this embodiment variant is that, in order to avoid any modification 
of the client applications source code, it is not necessary to set the source IP 
address of the eventual client services to "loopback" address. In fact, in this 
5 case the source IP address is the client application device PAN IP address 
("ClientlP") 18. Since it does not change during a switch phase (only the 
CNAPT Internet IP address 19 changes), the client services will not be 
interrupted. 

In an embodiment variant, the "Multi-Server LAN configuration", the 
CNAPT module is installed on the client application mobile device 10 and the 
SNAPT module is installed on an additional dedicated device 70 placed in the 
same network of the original server device 20 (Figure 14); in this way a unique 
SNAPT module can manage more server applications on different devices at a 
time. The CNAPT module sets the SNAPT IP address for each server service to 
"SNAPTIP" (51 ). On the client side, the CNAPT module comprises means to 
emulate the servers' services providing a server socket 
"loopback:ServiceEmulator n 16 for each of them ("loopback:Service1A M ,.., 
M loopback:Service1Z,.., "loopbackiServiceNA",..., "loopback:ServiceNZ"). This 
socket can handle multiple concurrent client requests. The client application 
accesses the services by sending and receiving data to/from these sockets. The 
SNAPT module emulates the client application requests providing a socket 
a SNAPTIP:CasualPort n 60 for each of them. The server applications (1 ..N) 
handle client requests by sending and receiving data to/from these sockets. 
This embodiment variant has the advantage that a SNAPT module can manage 
simultaneously more different server applications running on different devices 
on the same network; in this way a company that provides more and 
differentiated server services can offer to its customers the seamless handover 
feature using a unique SNAPT device. 

In an embodiment variant, the "Multi-Server Internet configuration", 
30 the CNAPT module is installed on the client application mobile device 10 and 
the SNAPT module is installed on an additional dedicated Internet server 70 
placed on an Internet site reachable from the CNAPT module and different from 
the Internet sites 20 running the server applications (Figure 15). This way the 
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mobile device 1 0 is able to benefit by the above-mentioned advantages of the 
invention with any server providing services on the network, e.g. the Internet, 
without the need to have a SNAPT module installed on every single server of 
interest. The CNAPT module sets the SNAPT IP address for each server 

s service to "SNAPTIP" (51). On the client side, the CNAPT module comprises 
means to emulate the Servers' services, providing a server socket 
"loopback:ServiceEmulator" 16 for each of them ("loopback:Service1A",.., 
"loopback:Service1Z,.., "loopback:ServiceNA" "loopback:ServiceNZ"). This 
socket can handle multiple concurrent Client requests. The Client application 

10 accesses the services by sending and receiving data to/from these sockets. The 
SNAPT module comprises means to emulate the client application requests 
providing a socket "SNAPTIP:CasualPort" 60 for each of them. The servers 
applications (1..N) handle client requests by sending and receiving data to/from 
these sockets. This embodiment variant has the advantage that a SNAPT 

15 module, installed on an Internet node, can manage simultaneously more 

different server applications running on different Internet nodes. In this way the 
seamless handover of the network connection among one or more client 
applications and one or more server applications can be provided by a 
company, different from the services providers, that does not require any 

20 modification or installation on the services providers sites and that only requires 
the installation of the CNAPT module on the final customer mobile device. With 
such embodiment variant, following a switch between network access 
technology and/or provider, a customer of the above-described company (e.g. 
an active trader) would be able to maintain active different trading sessions with 

25 different trading service providers. 

In an embodiment variant, the "Client PAN Multi-Server Internet 
configuration", the CNAPT module is installed on an additional mobile device, 
that could act as a "connectivity box" able to manage the highest possible 
number of network access technologies and linked to a set of mobile devices 
30 through a broadband IP connection (Figure 16). The client applications' mobile 
devices and the "connectivity box" have a fixed private IP address each, 
"Client1IP".."ClientNIP n and "CBoxlP": they are part of a very small local 
network (e.g. they are connected using an Ethernet hub or a Wi-Fi ad-hoc 
connection or a Bluetooth connection). The Servers' IP addresses are set to the 
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"connectivity box" IP address ("CBoxlP") in the client applications. The CNAPT 
module sets the SNAPT IP address for each server service to "SNAPTIP" and 
sets the client IP address for each client service to the IP address of the mobile 
device running the related client application ("ClientllP" for client service 1 A, 

5 1B...1Z , "ClientNIP" for client service IMA, NB...NZ). The SNAPT module is 
installed on an additional dedicated network server or Internet server 70 placed 
on an Internet site reachable from the CNAPT module and different from the 
Internet sites 20 running the server applications. This way the mobile devices 
are able to benefit by the above-mentioned advantages of the invention with 

10 any server providing services on the network and/or Internet, without the need 
to have a SNAPT module installed on every single server of interest. The 
CNAPT module comprises means to emulate the servers' services providing a 
server socket "CBoxlP:ServiceEmulator" for each of them. This socket can 
handle multiple concurrent client requests. The client applications access the 

is services by sending and receiving data to/from these sockets. The SNAPT 
module comprises means to emulate the client applications' requests providing 
a socket "SNAPTIPiCasualPort" for each of them. The servers' applications 
(1..N) handle client requests by sending and receiving data to/from these 
sockets. With such configuration, following a switch between network access 

20 technology and/or provider; for instance, an active trader would be able to 
maintain active multiple different sessions with multiple different service 
providers (e.g. a trading session with his laptop, a voice call with his VoicelP 
Phone and a medical monitor session with his biometric sensors). This 
embodiment variant combines the advantages of the "Multi-Server Internet 

25 configuration" and the "Client PAN configuration". 

The set of embodiment variants described above is not intended to 
be exhaustive: it will be understood that further permutations of the base 
configurations and various changes in form and in detail may be made therein 
without departing from the spirit and the scope of the invention. The concept of 
30 the invention has been explained using a simplified model, but this concept is, 
obviously, more general: (1) The CNAPT module can emulate a great number 
of server and client services and can handle multiple concurrent requests to the 
same client or server service or to different services. (2) The CNAPT module 
can handle any number of client applications resident on the same device or in 
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different devices. (3) The SNAPT module can handle multiple concurrent client 
requests coming from the same CNAPT module as well as multiple concurrent 
client requests coming from different CNAPT modules. (4) The SNAPT module 
can handle multiple concurrent server requests of client services coming from 
s the same server application as well as multiple concurrent server requests 
coming from different server applications. (5) The SNAPT module can handle 
any number of server applications resident on the same device or in different 
devices. 

In an embodiment variant, a system according with the invention can 
10 support the dynamic update of the QoS (Quality of Service) parameters of the 
client and the server applications following a switch between two different 
network providers. In fact the switch between two different network providers 
could sometimes determine a relevant variation in the bandwidth available or in 
others connection parameters like packet delay, packet loss probability etc. This 
is variation should entail a QoS (Quality of Service) variation whenever the client 
and the server applications could dynamically change it. For instance, if the 
client and the server applications provide a real-time videoconference system, 
at their start a set of QoS parameters are exchanged and defined: frame rate, 
picture format, compression quality, ...etc. In case of bandwidth variation these 
20 applications should be able to adapt the QoS to the new conditions in order to 
provide the best possible service at all times. In such cases, the CNAPT module 
and the SNAPT module can be configured to send to the client and the server 
applications all the information they need to update their QoS. 

In another embodiment variant, the client and/or server services byte 
25 streams between the CNAPT module and the SNAPT module could be 
compressed in order to reduce the amount of data exchanged. The CNAPT 
module and the SNAPT module, of course, have to know which services byte 
streams have to be compressed. 

Description of the preferred embodiment 

30 In the following an embodiment of the invention based on the "Basic 

configuration" will be described in more detail. For this example of an 
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embodiment, it is assumed that the mobile device 10 using the client application 
1 1 is able to hold two different network connections simultaneously, e.g. 
Internet connections, through the network adapter 1 and 2 (40 and 41 in Figure 
17). The network adapter 1 and 2 are wireless adapters. In this example the 

5 server application 21 provides only two connection-oriented services (like 
services based on TCP): ServiceA and ServiceB (this assumption is used only 
to simplify the drawings; obviously the switch procedure handles also the 
connectionless server services). For each of them a server socket 29 listens for 
client application requests (Figure 17). The server device is connected to 

10 Internet 34 and it has the IP address "ServerlP". The mobile device 10, using 
the wireless adapter 1 [40], is connected to Internet 34 via the wireless provider 
1 [30] and it has the IP address tt ClientlP_/T. The client application does not 
provide any client services (this assumption is used only to simplify the 
drawings; obviously the switch procedure handles also the connection- 

is oriented/connectionless client services). The CNAPT module and the SNAPT 
module will be described as middleware software application installed 
respectively on the mobile device 10 and on the server PC 20. In a modified 
embodiment, the CNAPT module and the SNAPT module run on a dedicated 
device. In this case the client and the server applications send/receive packets 

20 to/from the external dedicated device. The unique difference from the other 
implementation is that the CNAPT module and SNAPT module are not referred 
to by the loopback address, but by their external dedicated device IP address. 

The CNAPT module is a software module that comprises means to 
emulate the server application on the client side 14 and means to emulate the 

25 client application on the Internet side 15 (Figure 18). With only the server IP, the 
services' real ports, the services' emulator ports and the services' type, it . 
provides: (1 ) for each server service, a server socket 16 on the client side. This 
server socket listens on the real service port (Server Service Emulator server 
socket). (2) For each server service request, a Client Request Emulation Socket 

30 121 on the Internet side. This socket relays packets to the right Service 
Emulator Server Socket provided by the SNAPT module. To understand the 
functionality of the CNAPT module, suppose that the mobile device 10 is 
connected to Internet via the wireless provider 1 and has the IP address 
a ClientlP_1 w . If the server IP address has been set to "loopback" in the client 
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application, when it requests the ServiceA, it sends a request to the 
a loopback:ServiceA w address 50. This request is received from the ServiceA 
Emulator server socket 16. The CNAPT module changes the source address 
from "loopback:ReqPort" 52 to M ClientlP_1:CasualPort)C 53 and the destination 
s address from "loopback:ServiceA n 50 to "ServerlPiServiceAEmulator" 54 and it 
then resends this request through the Client Request Emulator socket 121 . 
When the Client Request Emulator socket 121 receives the server response, 
the CNAPT module changes the source address from 

"ServerlPiServiceAEmulator" 55 to "loopback:ServiceA" 57 and the destination 
10 address from a ClientlP_1 : CasualPortX" 56 to "loopback:ReqPorf 58 and it then 

resends this response through the Server Service Emulator server socket 16. 

The CNAPT module and the SNAPT communicate through a "Control socket" 

122. This connection is used to exchange handshaking packets during an IP 

address-changing phase and to optimize the interaction between the client and 
15 the server application. This connection is not always on; it is established when 

the CNAPT module has some needs, and it is closed when the operation has 

been completed. 

If the client application provides some client services, they can also 
be emulated by the CNAPT module, but it has to know the client services 1 ports 

20 and type (connection-oriented or connectionless). With this information, the 
CNAPT module provides: (1 ) For each client service, a server socket 17 on the 
Internet side (Figure 8). This server socket listens on the client service emulator 
port (Client Service Emulator server socket). This port is difFerent from the real 
client service port in order to avoid a bind error. (2) For each client service 

25 request, a Server Request Emulation Socket 123 on the client side. This socket 
relays packets to the real client server socket 111. 

It is conceivable for a CNAPT module to emulate more than one 
server application simultaneously and in parallel. This CNAPT module can be 
used by more than one client application. 

30 The CNAPT module preferably has to be started before the client 

application. It has to run until the client application stops in order to provide it 
with a good, reliable and cost effective network connection to the server 
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application. The CNAPT module, at the start, does the following: (1) Obtains a 
network connection (Figure 20). If this is not possible, the CNAPT module can 
be stopped, for instance, and the client application cannot be started. (2) 
Launches the "decision task" module. (3) Creates the Server Service Emulator 

s server sockets 16 on the Client side 14. (4) Creates the Client Service Emulator 
server sockets 17 on the network side 15. (5) Creates a local Control socket 
122 connected to the SNAPT (or, in turn, to the SNAPTs in case of "Multi-Site 
configuration") Control server socket 27 and uses it to send a "CONNECT" 
packet from which the SNAPT can retrieve the CNAPT ID, its current IP 

10 address and the connection optimization parameters. When the SNAPT module 
receives the initial "CONNECT" packet, it does the following: (1) Checks 
whether it can handle the new connection (obviously it has limited resources). 

(2) If it cannot accept the new connection, it replies with a "REFUSED" packet 

(3) If it can accept a new connection, it stores the CNAPT ID and its current IP 
15 address. From now on, for this CNAPT ID, the SNAPT module will send all 

outgoing packets only to its current IP address. (3a) Allocates the internal 
resources for the new connection and adds the new CNAPT ID to the list of 
connected CNAPT modules. (3b) Creates on the Server side 24 the Client 
service emulator server sockets 28 related to the CNAPT ID and binds them to 

20 an available Virtual IP address 23. (3c) Sends the connect acknowledgement to 
the CNAPT module. The CNAPT module, at the end, has to create a local 
Control socket 122 connected to the SNAPT (or, in turn, to the SNAPTs in case 
of "Multi-Site configuration") Control server socket 27 and use it to send a 
"DISCONNECT' packet. When the SNAPT module receives a "DISCONNECT' 

25 packet it does the following: (1 ) Releases the internal resources of the 
disconnecting CNAPT ID and removes it from the list of connected CNAPT 
modules. (2) Destroys the Client service emulator server sockets 28 related to 
the CNAPT ID and unbinds them from the allocated Virtual IP address 23. (3) 
Sends the disconnect acknowledgement to CNAPT. The SNAPT module 

30 associates with each connected CNAPT module a maximum inactivity time 
(inactivity timeout). When this inactivity time has elapsed, the CNAPT will be 
considered disconnected, and the previous steps (1-3) will be executed. 

The SNAPT module can be produced as a software module that 
emulates the client application on the server side 24 and the server application 
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on the network or Internet side 25 (Figure 21). It provides: (1) For each server 
service, a server socket 26 on the Internet side 25. This server socket listens on 
the server service emulator port (Server Service Emulator server socket). This 
port is different from the real server service port in order to avoid a bind error. 

5 (b) For each service request, a Client Request Emulation Socket 60 on the 
server side 24. This socket relays packets to the real Service server socket 29. 
When the SNAPT module receives a ServiceA request, it changes the source 
address from "ClientlP_1 :CasualPortX" 62 to "loopbackrCasualPortY" 64 and 
the destination address from "ServerlP:ServiceAEmulator" 63 to 

10 "ServerlP:ServiceA" 65. It then resends this request through the Client Request 
Emulator socket 60. When the Client Request Emulator socket receives the 
server application response, the SNAPT changes the source address from 
"ServerlP:ServiceA" 66 to "ServerlP:ServiceAEmuIator" 68 and the destination 
address from "loopback.CasualPortY" 67 to "ClientlP_1 :CasualPortX w 69. It then 

is resends this response through the Server Service Emulator server socket 26. If 
the client applications provide some client services, they can also be emulated 
by the SNAPT module but it has to know the client services' ports and type 
(connection-oriented or connectionless), the CNAPT module services' emulator 
ports and for each client service the corresponding CNAPT module ID. With this 

20 information, the SNAPT module provides: (1) For each Client Service, a server 
socket 28 on the Server side. This server socket listens on the real Client 
Service port (Client Service Emulator server socket). (2) For each Client Service 
request, a Server Request Emulation Socket 61 on the network side, e.g. 
Internet side. This socket relays packets to the right Client Service Emulator 

25 Server Socket provided by the correspondent CNAPT module ID. 

The SNAPT module can comprise means to emulate more than one 
client application request simultaneously and in parallel, and the SNAPT module 
can be used by more than one server application. 

Suppose that the mobile device 10 is connected to the Internet via 
30 the Wireless Provider 1 [30], and it has the IP address "ClientlP_1 w . Suppose 
also that the client application 1 1 has already requested the ServiceA, and it is 
now exchanging data with the server application 21 (Figure 22). In this normal 
condition the "Control Socket" 122 is used only to exchange data for the 
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Client/Server connection optimization. In the following, to explain the switch 
procedure, two cases will be illustrated: first the Wireless Provider 1 [30] that 
gradually becomes unavailable (slow switch) and then the Wireless Provider 1 
that suddenly becomes unavailable (unexpected switch). 

5 Now suppose that the Wireless Provider 1 (30) gradually becomes 

unavailable (slow switch), for instance the mobile device 10 is slowly leaving its 
coverage area, while the Wireless Provider 2 (31) remains still available. In 
order to keep the client application and the session active, a new Internet 
connection through the Provider 2 must be established before the Provider 1 

10 becomes totally unavailable. If there is enough time for the IP transition phase 
(that is to say the Client and the Server applications don't go into timeout), the 
switch from the Wireless Provider 1 ("ClientlP_1") and the Wireless Provider 2 
("ClientlPJZ") is totally transparent to the client and server applications that 
continue their execution without any interruption of service and/or session. To 

is begin the IP transition phase from the Wireless Provider 1 ("ClientlP_1") to the 
Wireless Provider 2 ("Client I P_2"), the CNAPT module has to (note that to begin 
this phase it is not necessary to have the "ClientlP_2" IP address, the unique 
precondition is to know the wireless provider selected to retrieve the new IP, in 
this case the Wireless Provider 2): (CNAPT-1) Suspend the "decision task" 

20 module activities (Search and Check activities). (CNAPT-2) Stop forwarding the 
connection-oriented server services request packets to the SNAPT module. 
(CNAPT-3) Stop forwarding the connection-oriented client services reply 
packets to the SNAPT module. (CNAPT-4) Stop forwarding the connectionless 
server services packets to the SNAPT module. (CNAPT-5) Buffer the pending 

25 server service requests and the pending client service replies. They will be 
forwarded at the end of the IP transition phase. (CNAPT-6) Flush all the 
transmission buffers. (CNAPT-7) Wait until the Search/Check activities have 
been suspended. (CNAPT-8) Put the input stream of the connection-oriented 
sockets linked to the SNAPT module in "waiting for last packet before 

30 redirection" mode. These sockets continue to receive data from the SNAPT 
module as before, until they receive a 

"LASTJWESSAGE_BEFORE_REDIRECTION M packet (note that this step can 
be avoided for connectionless services because they can tolerate packet 
losses). (CNAPT-9) Create a new Control socket 122 "ClientlP_1:CasualPortK w 
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and connect it to the Control server socket 27 provided by SNAPT module on 
"ServerlP:ControlPort". (CNAPT-10) Send a "SWITCH_STEP1" packet to the 
SNAPTs Control server socket 27 using the Wireless Adapter 1 (Figure 23). 
This packet contains the CNAPT ID. (CNAPT-1 1) Wait for "SWITCH_STEP1" 
s packet reception confirmation from the SNAPT module. 

When the SNAPT module receives a "SWITCH_STEP1" packet, it 
has to (Figure 24): (SNAPT-1 ) Retrieve from this packet the ID of the sender 
CNAPT (from now on referred as "SWITCHING-CNAPT). (SNAPT-2) Stop 
forwarding the connection-oriented server service reply packets to the 

10 "SWITCHING-CNAPT. (SNAPT-3) Stop forwarding the connection-oriented 
client service request packets to the "SWITCHING-CNAPT. (SNAPT-4) Stop 
forwarding the connectionless client service packets to the "SWITCHING- 
CNAPT. (SNAPT-5) Buffer the pending server service replies and the pending 
client service requests. They will be forwarded at the end of the IP transition 

is phase. (SNAPT-6) Flush all the transmission buffers. (SNAPT-7) Put the input 
stream of the connection-oriented sockets linked to the "SWITCHING-CNAPT 
in "waiting for last packet before redirection" mode. These sockets continue to 
receive data from the "SWITCHING-CNAPT as before until they receive a 
"LAST_M ESS AG E_BE FO RE_ REDIRECTION" packet (note that this step can 

20 be avoided for connectionless services because they can tolerate packet 
losses). (SNAPT-8) Send a "LAST_MESSAGE_BEFORE_REDIRECTION M 
packet in each output stream of the connection-oriented sockets linked to the 
"SWITCHING-CNAPT. (SNAPT-9) Confirm to the "SWITCHING-CNAPT 
control socket 122 the reception of the "SWITCH__STEP1 " packet with an "ACK" 

25 packet. (SNAPT-1 0) Wait until all the input streams in "waiting for last packet 
before redirection" mode have received the 
"LAST_MESSAGE_BEFORE_REDIRECTION" packet. 

When the CNAPT module receives the SNAPT module 
acknowledgement, it has to (Figure 25): (CNAPT-1 2) Send a 
30 "LAST_MESSAGE_BEFORE_REDIRECTION" packet in each output stream of 
the connection-oriented sockets linked to the SNAPT. (CNAPT-1 3) Wait until all 
the input streams in "waiting for last packet before redirection" mode have 
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received the "LAST_MESSAGE_BEFORE_REDlRECTION" packet. (CNAPT- 
14) Wait for SNAPTs a OK_TO_REDIRECTION" packet. 

When the SNAPT module has received all the 
"LAST_MESSAGE_BEFORE_REDIRECTION" packets, it has to (Figure 26): 
s (SNAPT-1 1 ) Send an a OK_TO_JREDIRECTION w packet to the "SWITCHING- 
CNAPT" control socket 122. (SNAPT-1 2) Wait for the 

w CLIENT_SERVICES_READY_FOR_REDIRECTION" packet coming from the 
"SWITCHING-CNAPT control socket 122. 

When the CNAPT module receives the "OK_TO_REDIRECTION " 
10 packet, it has to (Figure 27): (CNAPT-15) Destroy the connectionless Client 
Services Emulator sockets 17 bound to the current CNAPT IP address and 
receiving data from the SNAPT. (CNAPT-16) Preserving the Client services 
connections between the Client and the Server applications, destroy the Client 
services connection-oriented emulation sockets linked to the SNAPT and 
is generated by the connection-oriented Client Services Emulator server sockets 
17. They were bound to the current CNAPT IP address. Each of these sockets 
has to be renewed by the SNAPT in order to preserve the Client services 
connections between the Client and the Server applications. (CNAPT-17) 
Preserving the Client services connections between the Client and the Server 
20 applications, destroy the connection-oriented Client Services Emulator server 
sockets 17 accepting requests from the SNAPT. They were bound to the 
current CNAPT IP address. (CNAPT-18) Send a 

M CLIENT_SERVICES_READY_FOR_REDIRECTION" packet to the SNAPTs 
control server socket 27. (CNAPT-1 9) Wait for the 
25 "SERVER_SERVICES_READY — FOR_REDIRECTION n packet coming from the 
SNAPTs control server socket 27. 

When the SNAPT module receives the 
a CLIENT_SERVICES_READY_FOR__REDIRECTION" packet, it has to (Figure 
28): (SNAPT-1 3) Preserving the Client services connections between the Client 
30 and the Server applications, destroy the connection-oriented Client Services 
Server Request Emulation sockets 61 linked to the current "SWITCHING- 
CNAPT IP address. (SNAPT-1 4) Preserving the Server services connections 
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between the Client and the Server applications, destroy the Server services 
connection-oriented emulation sockets linked to the current "SWITCHING- 
CNAPT" IP address and generated by the connection-oriented Server Services 
Emulator server sockets 26. Each of these sockets has to be renewed by the 

5 "SWITCH I NG-CNAPT" in order to preserve the Server services connections 
between the Client and the Server applications. (SNAPT-15) Send a 
"SERVER_SERVICES_READY_FOR_REDIRECTION M packet to the 
"SWITCHING-CNAPT control socket 122. (SNAPT-16) Wait for the 
"SWITCH_STEP2" packet coming from the "SWITCHING-CNAPT through the 

10 new control socket 122 bound to its new IP address. 

When the CNAPT module receives the 
"SE RVER_S ERVICES_READ Y_FOR_RED I RECTI ON " packet, it has to 
(Figure 29): (CNAPT-20) Preserving the Server services connections between 
the Client and the Server applications, destroy the connection-oriented Server 

is services Client Request Emulation sockets 121 bound to the current 

"SWITCHING-CNAPT' IP address. (CNAPT-21) Destroy the control socket 122 
bound to the current "SWITCHING-CNAPT" IP address. (CNAPT-22) If needed, 
close the old Internet connection through the Wireless Provider 1 (if the client 
application and the server application are connected through a VPN, this step 

20 has to be preceded by the following step: Close the existing VPN connection 
between "ClientlP_1 w and "ServerlP"). (CNAPT-23) If the "ClientlP_2" address is 
not yet available, open the new Internet connection through the selected 
wireless adapter (in this case the Wireless Adapter 2). (CNAPT-24) Change the 
current IP address from the old IP address to the new one (if the client 

25 application and the server application are connected through a VPN, this step 
has to be followed by the following step: Open the new VPN between 
"ClientlP_2" and "ServerlP"). (CNAPT-25) Change to the new CNAPT IP 
address the binding of the server services connectionless sockets transmitting 
to the SNAPT module. (CNAPT-26) Recreate the connectionless Client 

30 Services Emulator sockets 17 receiving data from the SNAPT and bind them to 
the new CNAPT IP address. (CNAPT-27) Preserving the Client services 
connections between the Client and the Server applications, recreate the 
connection-oriented Client Services Emulator server sockets 17 accepting 
requests from the SNAPT and bind them to the new CNAPT IP address. 
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(CNAPT-28) Create a new control socket 122 "CiientlP_2:CasualPort ,, and 
connect it to the control server socket 27 provided by SNAPT module on 
"ServerlPiControlPorT. (CNAPT-29) Send a "SWITCH_STEP2 n packet to the 
SNAPT's control server socket 27 using the Wireless Adapter 2. This packet 

s contains the CNAPT ID and through this packet the SNAPT module can deduce 
the new CNAPT IP address. (CNAPT-30) Wait for the renewal of the 
connection-oriented Client services emulation sockets destroyed in [CNAPT- 
16]- This renewal will be done with a connection request [SNAPT-19] of the 
SNAPT for each connection-oriented socket generated by the Client Services 

10 Emulator server sockets 1 7. 

When the SNAPT module receives the a SWITCH_STEP2 n packet, it 
has to: (SNAPT-17) Update the "SWITCHING-CNAPT" IP address with its new 
IP address as retrieved by the source field of the "SWITCH_STEP2" control 
packet. (SNAPT-18) Redirect the Client services connectionless sockets 

is transmitting to the "SWITCHING-CNAPT from its old IP address to the new one 
(no redirection is needed for the connectionless server sockets receiving data 
from the "SWITCH I NG-CNAPT"; they are unaffected by the CNAPT IP address 
switch). (SNAPT-19) Recreate the connection-oriented Client Services Server 
Request Emulation sockets 61 destroyed in [SNAPT-13] and connect them, in 

20 order to preserve the Client/Server interaction, to the Client Services Emulator 
server sockets 17 provided on the new "SWITCH ING-CNAPT" IP address. 
(SNAPT-20) Wait for the renewal of the connection-oriented Server services 
emulation sockets destroyed in [SNAPT-14]. This renewal will be done with a 
connection request [CNAPT-32] of the M SWITCHING_CNAPT for each 

25 connection-oriented socket generated by the Server Services Emulator server 
sockets 26. 

When the CNAPT module has received the renewal of the 
connection-oriented Client services emulation sockets destroyed in [CNAPT-16] 
it has to (Figure 30): (CNAPT-31 ) Redirect the correspondent Client services 
30 emulation connections to the new IP address through the renewed emulation 
sockets in order to preserve the Client/Server interaction. (CNAPT-32) 
Recreate the connection-oriented Server services Client Request Emulation 
sockets 121 destroyed in [CNAPT-20], bind them to the new "SWITCHING- 
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CNAPT" IP address and connect them, in order to preserve the Client/Server 
interaction, to the Server Services Emulator server sockets 26 provided on the 
SNAPT IP address. (CNAPT-33) Wait for the "ALLJREDIRECTED" packet 
coming from the SNAPTs control server socket 27. 

5 When the SNAPT module receives the renewal of the connection- 

oriented Server services emulation sockets destroyed in [SNAPT-14] it has to 
(Figure 31): (SNAPT-21) Redirect the correspondent Server services emulation 
connections to the new "SWITCHING-CNAPT" IP address through the renewed 
emulation sockets in order to preserve the Client/Server interaction. (SNAPT- 

10 22) Send an "ALL_RE D I RECTE D w packet to the new "SWITCHING-CNAPT" 
control socket 122. (SNAPT-23) Wake up all the connectionless/connection- 
oriented client and server services and send the packets buffered in [SNAPT-5]. 

When the CNAPT module receives the "ALLJRED I RECTED" packet, 
it has to (Figure 32): (CNAPT-34) Wake up all the connectionless/connection- 
15 oriented client and server services and the "decision task" activities (Search and 
Check activities) and send the packets buffered in [CNAPT-5]. 

In the steps [CNAPT-1 1], [CNAPT-1 3], [CNAPT-14], [CNAPT-19], 
[CNAPT-30] and [CNAPT-33] the CNAPT waits for at most Z seconds (switch 
timeout). When this time has elapsed the CNAPT and the related Client 

20 application should be stopped. In the steps [SNAPT-10], [SNAPT-12], [SNAPT- 
16] and [SNAPT-20] the SNAPT waits for at most Z seconds (switch timeout). 
When this time has elapsed the SNAPT could consider the involved CNAPT as 
disconnected and it should execute these steps: (1) Release the internal 
resources of the disconnected CNAPT ID and remove it from the list of 

25 connected CNAPT. (2) Destroy the Client service emulator server sockets 

related to the CNAPT ID and unbind them from the allocated Virtual IP address. 

In case of "Multi-Site configuration n , some groups of steps are 
executed separately for each connected SNAPT and there are some 
synchronization steps. The steps CNAPT-9..13 are executed separately for 
30 each connected SNAPT. The step CNAPT-14 is a synchronization step for all 
the connected SNAPTs. When the step CNAPT-1 8 has been completed for all 
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the connected SNAPTs, the steps CNAPT-19..21 are executed separately for 
each of them. The steps CNAPT-28,29 are executed separately for each 
connected SNAPT. The steps CNAPT-32,33 are executed separately for each 
connected SNAPT. 

5 Suppose now that the Wireless Provider 1 becomes suddenly 

unavailable (unexpected switch), for instance the mobile device is rapidly 
leaving its coverage area, while the Wireless Provider 2 remains still available. 
In order to maintain active the client application and the session, a new Internet 
connection through the Provider 2 must be established. If there is enough time 

10 for the IP transition phase (that is to say the Client and the Server applications 
don't go into timeout), the switch from the Wireless Provider 1 ("ClientlP_1 H ) and 
the Wireless Provider 2 f ClientlP_2") is totally transparent to the Client and 
Server applications that continue their execution without any interruption of 
service and/or session. Note that the IP transition phase can be generated also 

15 by a temporary interruption of the Internet connection provided by the Wireless 
Provider 1 , that however remain still available; in fact that temporary interruption 
may cause a modification on the assigned IP, e.g. from "ClientlP_1" to 
"ClientlP^a". 

If the Wireless Provider 1 becomes suddenly unavailable the 
20 correspondent Internet connection will be suddenly interrupted. This interruption 
will throw on the CNAPT software some exceptions that are used to handle this 
particular event if and only if the CNAPT was reading or writing on the 
connection at the time of the interruption; otherwise the Check Activity signals 
the interruption and invokes the IP transition phase. The interruption will throw 
25 on the SNAPT software some exceptions that are used to handle this particular 
event if and only if the SNAPT was reading or writing on the connection to that 
CNAPT ID at the time of the interruption; otherwise the interruption is signalled 
by the reception of the "SWITCHJJN EXPECTED" packet from that CNAPT ID. 
The reception of the "SWITCHJJNEXPECTED" packet causes the invocation of 
30 the IP transition phase for that CNAPT ID. 

When the CNAPT catches the connection exception or when the 
Check Activity signals the interruption, the CNAPT has to establish a new 
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Internet connection through the Wireless Provider 2 (or, in turn, through the 
Wireless Provider 1 if it is became available in the meanwhile, e.g. there was 
only a temporary problem). When the new Internet connection is available, to 
begin the IP transition phase from the w ClientlP_T (no more available) to the 

5 tt ClientlP_2 w the CNAPT has to: (CNAPT-1 *) Suspend the "decision task" 
activities (Search and Check activities). (CNAPT-2*) Stop forwarding the 
connection-oriented Server services request packets to the SNAPT. (CNAPT- 
3*) Stop forwarding the connection-oriented Client services reply packets to the 
SNAPT. (CNAPT-4*) Stop forwarding the connectionless Server services 

10 packets to the SNAPT. (CNAPT-5*) Buffer the pending Server service requests 
and the pending Client service replies. They will be forwarded at the end of the 
IP transition phase. (CNAPT-6*) For each outgoing connection, store the 
eventual unsent packets (i.e. the packets that the outgoing connection was 
eventually sending when the interruption exception was caught). (CNAPT-7*) 

is Wait until the Search/Check activities have been suspended. (CNAPT-8*) 
Destroy the connectionless Client Services Emulator sockets 17 bound to the 
old CNAPT IP address. (CNAPT-9*) Preserving the Client services connections 
between the Client and the Server applications, destroy the Client services 
connection-oriented emulation sockets linked to the SNAPT and generated by 

20 the connection-oriented Client Services Emulator server sockets 17. They were 
bound to the old CNAPT IP address. Each of these sockets has to be renewed 
by the SNAPT in order to preserve the Client services connections between the 
Client and the Server applications. (CNAPT-1 0*) Preserving the Client services 
connections between the Client and the Server applications, destroy the 

25 connection-oriented Client Services Emulator server sockets 17 accepting 
requests from the SNAPT. They were bound to the old CNAPT IP address. 
(CNAPT-1 1*) Preserving the Server services connections between the Client 
and the Server applications, destroy the connection-oriented Server services 
Client Request Emulation sockets 121 bound to the old CNAPT IP address. 

30 (CNAPT-1 2*) Change the current IP address from the old IP address to the new 
one (if the client application and the server application are connected through a 
VPN, this step has to be followed by the following step: Open the new VPN 
between "ClientlP_2 w and a ServerlP n ). (CNAPT-1 3*) Change to the new CNAPT 
IP address the binding of the Server services connectionless sockets 

35 transmitting to the SNAPT. (CNAPT-1 4*) Recreate the connectionless Client 
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Services Emulator sockets 17 receiving data from the SNAPT and bind them to 
the new CNAPT IP address. (CNAPT-15*) Recreate the connection-oriented 
Client Services Emulator server sockets 17 accepting requests from the SNAPT 
and bind them to the new CNAPT IP address. (CNAPT-16*) Create a new 

5 Control socket "CIientlP_2:CasualPortK" and connect it to the Control server 
socket provided by SNAPT on "ServerlP:ControlPort". (CNAPT-17*) Send a 
"SWITCHJJNEXPECTED" packet to the SNAPT "Control server socket" using 
the new Internet connection. This packet contains the CNAPT ID and through 
this packet the SNAPT can deduce the new CNAPT IP address. (CNAPT-18*) 

10 Wait for the renewal of the connection-oriented Client services emulation 

sockets destroyed in [CNAPT-9*]. This renewal will be done with a connection 
request [SNAPT-1 1*] of the SNAPT for each connection-oriented socket 
generated by the Client Services Emulator server sockets 17. 

When the SNAPT catches the connection exception it waits for a 

is "SWITCHJJNEXPECTED" packet coming from that CNAPT ID. The SNAPT 
associates to that CNAPT ID a max reconnection waiting time (switch timeout). 
When this reconnection waiting time has elapsed, the related CNAPT will be 
considered definitely disconnected and the SNAPT should execute these steps: 
(1) release the internal resources of the disconnected CNAPT ID and remove it 

20 from the list of connected CNAPT; (2) destroy the Client service emulator server 
sockets related to the CNAPT ID and unbind them from the allocated Virtual IP 
address. When, in any way, the SNAPT receives a "SWITCHJJNEXPECTED" 
packet it has to: (SNAPT-1*) Retrieve from this packet the ID of the sender 
CNAPT (from now on referred as "SWITCHING-CNAPT"). Through this packet 

25 the SNAPT can also deduce the new "SWITCHING-CNAPT" IP address. 
. (SNAPT-2*) Stop forwarding the connection-oriented Server service reply 
packets to the "SWITCHING-CNAPT". (SNAPT-3*) Stop forwarding the 
connection-oriented Client service request packets to the "SWITCHING- 
CNAPT". (SNAPT-4*) Stop forwarding the connectionless Client service packets 

30 to the "SWITCHING-CNAPT". (SNAPT-5*) Buffer the pending Server service 
replies and the pending Client service requests. They will be forwarded at the 
end of the IP transition phase. (SNAPT-6*) For each outgoing connection, store 
the eventual unsent packets (i.e. the packets that the outgoing connection was 
sending when the interruption exception was caught). (SNAPT-7*) Preserving 
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the Client services connections between the Client and the Server applications, 
destroy the connection-oriented Client Services Server Request Emulation 
sockets 61 linked to the old "SWITCH I NG-CNAPT IP address. (SNAPT-8*) 
Preserving the Server services connections between the Client and the Server 

5 applications, destroy the Server services connection-oriented emulation sockets 
linked to the old "SWITCH I NG-CN APT" IP address and generated by the 
connection-oriented Server Services Emulator server sockets 26. Each of these 
sockets has to be renewed by the "SWITCHING-CNAPT in order to preserve 
the Server services connections between the Client and the Server applications. 

10 (SNAPT-9*) Update the "SWITCHING-CNAPT IP address with its new IP 
address as retrieved by the source address field of the 
"SWITCHJJNEXPECTED" control packet. (SNAPT-1 0*) Redirect the Client 
services connectionless sockets transmitting to the "SWITCHING-CNAPT from 
its old IP address to the new one (No redirection is needed for the 

is connectionless Server services sockets receiving data from the "SWITCHING- 
CNAPT". They are unaffected by the CNAPT IP address switch.). (SNAPT-1 1*) 
Recreate the connection-oriented Client Services Server Request Emulation 
sockets 61 destroyed in [SNAPT-7*] and connect them, in order to preserve the 
Client/Server interaction, to the Client Services Emulator server sockets 17 

20 provided on the new "SWITCHING-CNAPT IP address. (SNAPT-1 2*) Wait for 
the renewal of the connection-oriented Server services emulation sockets 
destroyed in [SNAPT-8*]. This renewal will be done with a connection request 
[CNAPT-21*] of the "SWITCHING-CNAPT 1 for each connection-oriented socket 
generated by the Server Services Emulator server sockets 26. 

25 When the CNAPT has received the renewal of the connection- 

oriented Client services emulation sockets destroyed in [CNAPT-9*] it has to: 
(CNAPT-19*) Redirect the correspondent Client services emulation connections 
to the new IP address through the renewed emulation sockets in order to 
preserve the Client/Server interaction. (CNAPT-20*) Recreate the connection- 

30 oriented Server services Client Request Emulation sockets 121 destroyed in 
[CNAPT-11*], bind them to the new "SWITCHING-CNAPT IP address and 
connect them, in order to preserve the Client/Server interaction, to the Server 
Services Emulator server sockets 26 provided on the SNAPT IP address. 
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(CNAPT-21*) Wait for the "ALLJREDIRECTED" packet coming from the SNAPT 
"Control server socket". 

When the SNAPT receives the renewal of the connection-oriented 
Server services emulation sockets destroyed in [SNAPT-8*] it has to: (SNAPT- 

5 13*) Redirect the correspondent Server services emulation connections to the 
new "SWITCH I NG-CN APT IP address through the renewed emulation sockets 
in order to preserve the Client/Server interaction. (SNAPT-14*) Send an 
M ALL — REDIRECTED" packet to the new "SWITCH ING-CNAPT" control socket. 
(SNAPT-15*) Resend the unsent packets eventually stored in [SNAPT-6*]. 

10 (SNAPT-16*) Wake up all the connectionless/connection-oriented Client and 
Server services and send the packets buffered in [SNAPT-5*]. 

When the CNAPT receives the "ALL_REDIRECTED W packet it has to: 
(CNAPT-22*) Resend the unsent packets eventually stored in [CNAPT-6*]. 
(CNAPT-23*) Wake up all the connectionless/connection-oriented Client and 
is Server services and the "decision task" activities (Search and Check activities) 
and send the packets buffered in [CNAPT-5*]. 

In the steps [CNAPT-1 8*] and [CNAPT-21*] the CNAPT waits for at 
most Z seconds (switch timeout). When this time has elapsed the CNAPT and 
the related Client application should be stopped. When the SNAPT is waiting 

20 for the "SWITCHJJNEXPECTED" packet coming from a switching CNAPT and 
in the step [SNAPT-12*], the SNAPT waits for at most Z seconds (switch 
timeout). When this time has elapsed the SNAPT could consider the involved 
CNAPT as disconnected and it should execute these steps: (1) Release the 
internal resources of the disconnected CNAPT ID and remove it from .the list of 

25 connected CNAPT. (2) Destroy the Client service emulator server sockets 

related to the CNAPT ID and unbind them from the allocated Virtual IP address. 

In case of "Multi-Site configuration", some groups of steps are 
executed separately for each connected SNAPT and there are some 
synchronization steps. The steps CNAPT-1 6*/1 7* are executed separately for 
30 each connected SNAPT. The step CNAPT-1 8* is a synchronization step for all 
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the connected SNAPTs. The steps CNAPT-20*/21* are executed separately for 
each connected SNAPT. 

It is obvious that the minimal duration of the IP transition phase, 
therefore the connection timeout of the client and the server application, must 

5 be higher than the time requested for the SNAPT module and CNAPT module 
activities described above. At the end of the IP transition phase, the CNAPT 
module and the SNAPT module, if suitably configured, could additionally send 
to the client/server applications special information, e.g. all the information they 
need to update their QoS (Quality of Service) etc. Furthermore it is clear that 

10 the above description is based on a set of assumptions for this specific 
example. However, the scope of the invention encompasses many different 
embodiments or examples for implementing different features of the invention. 
Therefore the described example is not intended to limit the invention in any 
way. While the invention has been particularly shown and described with 

15 reference to the preferred embodiment, it will be understood by those skilled in 
the art that various changes in form and in detail may be made therein without 
departing from the scope of the invention. 

A system according to the invention, e.g. based on wireless 
technologies, can help organizations to improve and diversify their range of 

20 services. For instance that system can help the companies 1 mobile field forces 
to convey to their customers a sense of efficiency, competence and customer- 
centric "philosophy". Such system provides the User with the best Internet 
connection in term of bandwidth, reliability and cost effectiveness among all the 
wired/wireless network access technologies and/or access providers available 

25 at a certain time and location. Let's consider a User connected via GPRS to a 
competence centre using videoconference and shared whiteboard, i.e. a 
collaboration application. If the User is moving from an only GPRS covered area 
to a Wi-Fi covered area, for instance he is going to an airport, the system 
according to the invention can ask him if he wants to switch to the available Wi- 

30 Fi connection. If he accepts it can switch, automatically or with a limited user 
interaction, from the old GPRS connection to the new Wi-Fi connection. The 
switch is totally transparent for the collaboration application (no restart is 
needed). The used services remain up and running, and the User experiences a 
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better QoS (as a matter of fact in this case the videoco inference and shared 
whiteboard performance improves). Let's now consider the case where the 
same User leaves the Wi-Fi covered area. In this case the system can detect 
the Wi-Fi signal strength degradation, and before the Wi-Fi signal disappears it 

5 automatically makes a switch to a GPRS connection if the GPRS signal is 
present. Also in this case the switch is totally transparent for the collaboration 
application (no restart is needed). The User only experiences a worse QoS, but 
the services remain up and running. A system according to the invention 
requires only limited CPU and/or memory resources so it can be used with 

10 PDAs and smart-phones, not only with laptops. Operating at application level 
(L7 of the OSI-7 Layers Protocols Stack), that system can be easily and quickly 
adapted to the wireless world innovation and, moreover, it can use all the 
widespread commercial products at transport (L4) or network (L3) or below level 
(L1 , L2) to provide all the security features. It doesn't require the implementation 

is of any custom security feature. Finally, the porting to the various operating 
systems (Windows NT-2000-CE-Mobile, Linux, Symbian, PalmOS, etc.) can 
be easily achieved by using Java technologies wherever it is possible. 



